SQL注入
即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息
- 数据库 : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。
- 数据库管理系统 : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
- 数据库系统 : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。
- 数据库管理员 : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统。
-
- 元组 ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。
码
- ：码就是能唯一标识实体的属性，对应表中的列。
候选码
- ： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。
主码
- : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但可以有多个候选码。
外码: 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。外键用于与另一张表的关联
主属性
- ： 候选码中出现过的属性称为主属性。
非主属性：
- 不包含在任何一个候选码中的属性称为非主属性。
- 主表（父表）：对于两个具有关联关系的表而言，相关联字段中主键所在的表就是主表。
- 从表（子表）：对于两个具有关联关系的表而言，相关联字段中外键所在的表就是从表。
定义一个外键时，需要遵守下列规则：
- 父表必须已经存在于数据库中，或者是当前正在创建的表。如果是后一种情况，则父表与子表是同一个表，这样的表称为自参照表，这种结构称为自参照完整性。
- 必须为父表定义主键。
- 主键不能包含空值，但允许在外键中出现空值。也就是说，只要外键的每个非空值出现在指定的主键中，这个外键的内容就是正确的。
- 在父表的表名后面指定列名或列名的组合。这个列或列的组合必须是父表的主键或候选键。
- 外键中列的数目必须和父表的主键中列的数目相同。
- 外键中列的数据类型必须和父表主键中对应列的数据类型相同。
为什么不要用外键呢?
增加了复杂性：
a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便;
b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦、
对分库分表不友好 ：因为分库分表下外键是无法生效的。
外键好处：
外键的主要作用是保持数据的一致性、完整性。
级联操作方便，减轻了程序代码量；
什么是 ER 图？
实体-联系图(Entity-Relation Diagram)用来建立数据模型,在数据库系统概论中属于概念设计阶段，形成一个独立于机器，独立于DBMS的ER图模型。
通常将它简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图提供了表示实体（即数据对象）、属性和联系的方法，用来描述现实世界的概念模型
数据库范式
1NF(第一范式)
属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求
2NF(第二范式)
2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖
3NF(第三范式)
3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖.基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。
函数依赖
- 函数依赖（functional dependency） ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
- 部分函数依赖（partial functional dependency） ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
- 完全函数依赖(Full functional dependency) ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
- 传递函数依赖 ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。传递函数依赖会导致数据冗余和异常。
主键、外键和索引的区别
存储过程
存储过程看成是一些 SQL 语句的集合。。存储过程一旦调试完成通过后就能稳定运行，另外，使用存储过程比单纯 SQL 语句执行要快，因为存储过程是预编译过的
存储过程在互联网公司应用不多，因为存储过程难以调试和扩展，而且没有移植性，还会消耗数据库资源。
drop、delete 与 truncate 区别
用法不同
- drop(丢弃数据):
drop table 表名，直接将表都删除掉，在删除表的时候使用。 - truncate (清空数据) :
truncate table 表名，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。 - delete（删除数据）
truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。
属于不同的数据库语言
truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。
而 delete 语句是 DML (数据库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。
DML 语句和 DDL 语句区别：
- DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。
- DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。
执行速度不同
一般来说：drop > truncate > delete
delete命令执行的时候会产生数据库的binlog日志，而日志记录是需要消耗时间的，但是也有个好处方便数据回滚恢复。
数据库设计通常分为哪几步?
- 需求分析 : 分析用户的需求，包括数据、功能和性能需求。
- 概念结构设计 : 主要采用 E-R 模型进行设计，包括画 E-R 图。
- 逻辑结构设计 : 通过将 E-R 图转换成表，实现从 E-R 模型到关系模型的转换。
- 物理结构设计 : 主要是为所设计的数据库选择合适的存储结构和存取路径。
- 数据库实施 : 包括编程、测试和试运行
- 数据库的运行和维护 : 系统的运行与数据库的日常维护。
事务基础
事务是逻辑上的一组操作，要么都执行，要么都不执行
事务的提交是指事务里的所有操作都正常完成。
事务的回滚是指程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。
何时用事务
事务的提出主要是为了解决并发情况下保持数据一致性的问题（类似于多线程）
当你的操作非原子性、并且一旦出现问题会影响业务流程时，就需要用事务
事务的四大特性
原子性：是指事务是一个不可分割的工作单位，事务中的操作要么全部成功，要么全部失败。比如在同一个事务中的SQL语句，要么全部执行成功，要么全部执行失败。
一致性（Consistency）:事务必须使数据库从一个一致性状态变换到另外一个一致性状态。
换一种方式理解就是：事务的一致性是指事务执行前后，数据都是正确的，不存在矛盾
隔离性（Isolation）:事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）:持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的
事务隔离级别有哪些
ANSI SQL标准定义了4种事务隔离级别来避免3种数据不一致的问题。事务等级从高到低，分别为：
1.Serializable（序列化）
最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰。innoDB 存储引擎在 分布式事务 的情况下一般会用到 SERIALIZABLE(可串行化) 隔离级别。
可能导致大量的超时现象和锁竞争。
2.Repeatable read（可重复读）
这是MySQL的默认事务隔离级别
对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改---幻读 ---一个事务内两次读取的结果集数目不同，重点是新增或删除
3.Read Committed（已提交读）
允许读取并发事务已经提交的数据。大部分数据库系统的隔离级别都是 READ-COMMITTED(读取提交内容) -----不可重复读 --在一个事务中两次读取同一条数据的结果不同，重点是修改
4.Read Uncommitted（未提交读）
最低的隔离级别，允许读取尚未提交的数据变更---导致脏读、（一个事务读取了另一个事务未提交的数据）
3种数据不一致问题
脏读、幻读和不可重复读
1、脏读：一个事务读取了另一个事务未提交的数据 张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。 与此同时， 事务B正在读取张三的工，读取到张三的工资为8000。 随后， 事务A发生异常，而回滚了事务。张三的工资又回滚为5000。 最后， 事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。 2、不可重复读：在一个事务中两次读取同一条数据的结果不同，重点是修改 例如： 在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。 与此同时， 事务B把张三的工资改为8000，并提交了事务。 随后， 在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。 3、幻读：一个事务内两次读取的结果集数目不同，重点是新增或删除 例如： 目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。 此时， 事务B插入一条工资也为5000的记录。 这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。
不可重复读的重点是修改：
同样的条件，你读取过的数据，再次读取出来发现值不一样了
幻读的重点在于新增或者删除：
同样的条件，第 1 次和第 2 次读出来的记录数不一样
简述MySQL中的日志log
https://www.cxyxiaowu.com/20412.html
日志是 mysql 数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。
作为开发，我们重点需要关注的是二进制日志( binlog )和事务日志(包括redo log 和 undo log )，本文接下来会详细介绍这三种日志。
binlog
binlog 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。
binlog 是 mysql的逻辑日志，并且由 Server 层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。
binlog 是通过追加的方式进行写入的，可以通过max_binlog_size 参数设置每个 binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。并不会覆盖以前的日志
binlog使用场景
在实际应用中， binlog 的主要使用场景有两个，分别是 主从复制 和 数据恢复 。
- 主从复制 ：在
Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。 - 数据恢复 ：通过使用
mysqlbinlog工具来恢复数据。
对于 InnoDB 存储引擎而言，只有在事务提交时才会记录biglog ，此时记录还在内存中，那么 biglog是什么时候刷到磁盘中的呢？
mysql 通过 sync_binlog 参数控制 biglog 的刷盘时机，取值范围是 0-N：
- 0：不去强制要求，由系统自行判断何时写入磁盘；
- 1：每次
commit的时候都要将binlog写入磁盘； - N：每N个事务，才会将
binlog写入磁盘。
从上面可以看出， sync_binlog 最安全的是设置是 1 ，这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，
因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。
redo log
作用
那么 mysql是如何保证持久性的呢？
最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：
- 因为
Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ - 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！
因此 mysql 设计了 redo log ， 具体来说就是只记录事务对数据页做了哪些**修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。**
redo log只会记录未刷入磁盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。
概念
redo log 包括两部分：一个是内存中的重做日志缓冲( redo log buffer )，另一个是磁盘上的重做日志文件( redo logfile)。
mysql 每执行一条 DML 语句，先将记录写入 redo log buffer，后续某个时间点再一次性将多个操作记录写到 redo log file。这种 先写日志，再写磁盘 的技术就是 MySQL里经常说到的 WAL(Write-Ahead Logging) 技术。
在计算机操作系统中，用户空间( user space )下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间( kernel space )缓冲区( OS Buffer )。
因此， redo log buffer 写入 redo logfile 实际上是先写入 OS Buffer ，然后再通过系统调用 fsync() 将其刷到 redo log file中
redo log与binlog区别
其他不同：redo log是物理日志，记录的是在具体某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑。
undo log
原子性 底层就是通过 undo log 实现的。undo log主要记录了数据的逻辑变化，比如一条 INSERT 语句，对应一条DELETE 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。
只靠binlog可以支持数据库崩溃恢复吗？
不可以
（1）事务恢复过程可以理解为是要把没有提交的事务的页面改动都去掉，并把已经提交的事务的页面改动都加上去这样一个过程
binlog记录着数据行的增删改，但是不记录事务对数据页的改动，这样细致的改动只记录在redo log中。
（2）操作写入binlog可细分为write和fsync两个过程，write指的就是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘,fsync才是将数据持久化到磁盘的操作。
通过参数设置sync_binlog为0的时候，表示每次提交事务都只write，不fsync。此时数据库崩溃可能导致部分提交的事务以及binlog日志由于没有持久化而丢失。
InnoDB如何保证事务的原子性、持久性和一致性和隔离性？数据库事务的运行原理
undo log回滚日志保证事务的原子性
该log保存了事务发生之前的数据的一个版本，可以用于回滚，从而保证事务原子性。
根据redo log进行重做，从而使事务有持久性。
那么如何保证事务的持久性呢？
一个简单的做法就是在事务提交完成之前，把该事务修改的所有页面都刷新到磁盘，但是这个粗暴的做法存在下面这些问题：
(1) 刷新一个完整的数据页太浪费时间了，有时我们仅仅修改了某个页面中的一个字节，但是由于InnoDB是以页为单位进行磁盘IO的，也就是事务提交时不得不将一个完整的页面刷新到磁盘，太浪费了。
(2) 随机IO刷新的比较慢，一个事务可能包含很多语句，即使是一条语句也可能修改许多页面，而且这些页面可能并不相邻。这就意味着在将某个事务修改的Buffer Pool中的页面刷新到磁盘时，需要进行很多的随机IO。
我们只是想让已经提交了的事务对数据库中的数据所在的修改能永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复过来。所以，其实没有必要在每次提交事务时就把该事务在内存中修改过的全部页面刷新到磁盘，只需要把修改的内容记录下来即可。
比如，某个事务将系统表空间中第10号 页面中偏移量为 100 处的那个字节的值 1 改成 2 。我们只需要记录一下：
将第0号表 空间的10号页面的偏移量为100处的值更新为 2
- 1
- 1
这样在事务提交时，就会把上述的内容刷新到磁盘中，即使之后系统崩溃了，重启之后只要按照上述内容所记录的步骤重新更新一下数据页，那么该事务对数据库中所做的修改就可以被恢复过来，这样就能满足持久性的要求了。
因为在系统因崩溃而重启时需要按照上述内容所记录的步骤重新更新数据页，所以上述内容也称为重做日志。
https://blog.csdn.net/weixin_42073461/article/details/124543270
利用锁（共享、排他）和MVCC 来保证事务的隔离性
保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障
MySQL 基本架构
简单来说 MySQL 主要分为 Server 层和存储引擎层：
- Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binlog 日志模块。
- 存储引擎： 主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，
- 其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了
1) 连接器
连接器主要和身份认证和权限相关的功能相关，就好比一个级别很高的门卫一样。
主要负责用户登录数据库，进行用户的身份认证，包括校验账户密码，权限等操作，如果用户账户密码已通过，连接器会到权限表中查询该用户的所有权限，
之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只要这个连接不断开，即使管理员修改了该用户的权限，该用户也是不受影响的。
2)查询缓存(MySQL 8.0 版本后移除)
查询缓存主要用来缓存我们所执行的 SELECT 语句以及该语句的结果集。
连接建立后，执行查询语句的时候，会先查询缓存，MySQL 会先校验这个 sql 是否执行过，以 Key-Value 的形式缓存在内存中，Key 是查询预计，Value 是结果集。
如果缓存 key 被命中，就会直接返回给客户端，如果没有命中，就会执行后续的操作，完成后也会把结果缓存起来，方便下一次调用。当然在真正执行缓存查询的时候还是会校验用户的权限，是否有该表的查询条件。
MySQL 查询不建议使用缓存，因为查询缓存失效在实际业务场景中可能会非常频繁，假如你对一个表更新的话，这个表上的所有的查询缓存都会被清空。对于不经常更新的数据来说，使用缓存还是可以的。
所以，一般在大多数情况下我们都是不推荐去使用查询缓存的。
MySQL 8.0 版本后删除了缓存的功能，官方也是认为该功能在实际的应用场景比较少，所以干脆直接删掉了。
3)分析器
第一步，词法分析，一条 SQL 语句有多个字符串组成，首先要提取关键字，比如 select，提出查询的表，提出字段名，提出查询条件等等。做完这些操作后，就会进入第二步。
第二步，语法分析，主要就是判断你输入的 sql 是否正确，是否符合 MySQL 的语法。
4) 优化器
优化器的作用就是它认为的最优的执行方案去执行（有时候可能也不是最优，这篇文章涉及对这部分知识的深入讲解），比如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等。
可以说，经过了优化器之后可以说这个语句具体该如何执行就已经定下来。
5) 执行器
当选择了执行方案后，MySQL 就准备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，就会去调用引擎的接口，返回接口执行的结果
一条 SQL 查询语句的执行过程
- 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在 MySQL8.0 版本以前，会先查询缓存，如果有直接缓存，如果没有，执行下一步
- 分析器进程词法分析、语法分析
- 优化器根据自己的优化算法进行选择执行效率最好的一个方案（优化器认为，有时候不一定最好）。那么确认了执行计划后就准备开始执行了
-
执行器进行权限校验，如果没有权限就会返回错误信息，如果有权限就会调用数据库引擎接口，返回引擎的执行结果。
一条更新SQL语句执行的过程是什么
可以看到，所谓两阶段提交，其实就是把 redo log 的写入拆分成了两个步骤：prepare 和 commit。
为什么 redo log 需要两阶段提交
使用反证法来思考，redo log 和 binlog 是两个独立的逻辑，如果我们的 redo log 不使用两阶段提交，要么就是先写完 redo log 再写 binlog，要么就是先写完 binlog 再写 redo log。我们看看这两种方式会出现什么问题。
我们仍然执行上面的更新语句，假设表的当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完的期间发生了 crash，会出现什么情况呢？
先写 redo log 后写 binlog。
假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。
先写 binlog 后写 redo log。
如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了 “把 c 从 0 改成 1” 这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。
综上所示，我们得出了结论，为什么 redo log 需要两阶段提交？因为，两阶段提交就是让 redo log 和 binlog 表示事务的提交状态的逻辑保持一致。
redo log 和 binlog 具有关联性，在恢复数据时，redo log 用于恢复主机故障时的未更新的物理数据，binlog 用于备份操作。每个阶段的 log 操作都是记录在磁盘的，在恢复数据时，redo log 状态为 commit 则说明 binlog 也成功，直接恢复数据；如果 redo log 是 prepare，则需要查询对应的 binlog 事务是否成功，决定是回滚还是执行
对上图的解释
为什么更新一条记录要把一整页数据加载到内存里？
答：因为Innodb引擎中，最小的存储单位是页
为什么一定要加载到内存里？
答：因为所有的计算操作都是在内存里，操作完成后最终才写回磁盘
事务是什么
数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，数据库并发控制的基本单位。
事务由事务开始与事务结束之间执行的全部数据库操作组成。数据库事务具有ACID这4个特性
为什么数据库不用红黑树用B+树
红黑树的出度为 2，而 B Tree （B-树就是指的B树）的出度一般都非常大。红黑树的树高 h 很明显比 B Tree 大非常多，IO次数很多，导致会比较慢，因此检索的次数也就更多。
B+Tree 相比于 B-Tree 更适合外存索引，拥有更大的出度，IO次数较少，检索效率会更高。
sql 语句执行底层
进程调度器
进程读取文件的过程
C++ 执行底层
JAVA c++ 区别
数据库 表关联
mysql 复制
Replay (SQL 再执行一遍 ) 需要将不同SQL对数据的修改写到不同的地方 。只有这里是随机读写
顺序读写效率高
具体步骤
mysql 为什么需要主从同步
1 读写分离
2访问激增时主机挂了，从机可保证提供正常的业务访问。
3多库存储 分散请求，保证对外持续提供服务
mysql 执行计划
1 根据TYPE
2 根据ID
开启查询缓存后在同样的查询条件以及数据情况下，会直接在缓存中返回结果。这里的查询条件包括查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息。