性能调优知识点（mysql）三

SQL底层执行原理
MySQL的内部组件结构：大体来说，MySQL 可以分为 Server 层和存储引擎层store两部分

Server层:主要包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
Store层:存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也就是说如果我们在create table时不指定表的存储引擎类型,默认会给你设置存储引擎为InnoDB。
Server层中连接器、查询缓存、分析器、优化器、执行器分别主要干了哪些事情。

连接器：连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接的时候先校验用户名和密码，然后才获取权限。
a.一个用户成功建立连接后，会创建一个会话空间，这个会话空间存储了用户名和密码及相关的权限，相关权限存储在user表中。所以即使你用管理员账号对这个用户的权限做了修改，只要连接没断开，也不会影响已经存在连接的权限，修改完成后，只有再新建的连接才会使用新的权限设置。用户的权限表在系统表空间的mysql的user表中。
b.数据库里面，连接分长连接和短连接。长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。
c.连接占用的内存在连接断开的时候才会释放。长连接有时会导致内存涨的非常快，如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。
怎么解决这类问题呢？1、定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。2、如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

查询缓存：mysql8.0已经移除了查询缓存功能。

分析器：如果缓存没命中，下一步就会由分析器处理。
词法分析器分成6个主要步骤完成对sql语句的分析1、词法分析2、语法分析3、语义分析4、构造执行树5、生成执行计划6、计划的执行。
也就是说词法分析器会将sql拆分构建成一颗语法树。
词源在分布式开发(比如分库分表，在第三期分库分表中讲到，还有分布式事务也用到)中很有用。
词法结构分析插件antlr v4

优化器：经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

执行器： 开始执行的时候，要先判断一下你对这个表T有没有执行查询的权限，如果没有，就会返回没有权限的错误。如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限。如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

事务
mysql设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制来解决多事务并发问题。

ACID
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
1.原子性(Atomicity) ：操作层面，所有操作都要执行。事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
2.一致性(Consistent) ：数据层面，所有数据都应正确更新。在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性。
3.隔离性(Isolation) ：每个事务之间的数据是不互相影响的，类似局部变量。数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
4.持久性(Durable) ：数据是持久化的。事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
还是转账来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。

并发事务处理带来的问题
1.更新丢失(Lost Update)或脏写
最后的更新覆盖了由其他事务所做的更新
2.脏读(读到事务B修改的数据)
事务A读取到了事务B已经修改但尚未提交的数据
3.不可重读
事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性
4.幻读（读到事务B新增的数据）
一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数
据，这种现象就称为“幻读”。
即事务A读取到了事务B提交的新增数据，不符合隔离性

事务隔离级别
分读未提交、读已提交、可重复读、可串行化
读未提交 read-uncommitted表示可以读到未提交的数据

锁
锁和事务、事务隔离级别是关联的,事务是通过锁来实现
1.锁分类
a.从性能上分为乐观锁(用版本对比来实现)和悲观锁
b.从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)
读锁（共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行而不会互相影响
写锁（排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁和读锁
c.从对数据操作的粒度分，分为表锁和行锁。可以给表或行加读锁、写锁。

事务中的悲观锁与乐观锁
悲观锁：修改数据时直接加锁，其他用户不能访问
乐观锁：用版本号来控制,版本号不改变的情况下可以进行其它事务操作

事务中的乐观锁和并发的乐观锁(比如CAS操作)类似，都是无锁，没有阻塞的。
悲观锁会进行阻塞。乐观锁不会阻塞(不会涉及锁等待)，在没有拿到锁的时候会回滚或重试。

读锁是共享锁，写锁是排他锁。

表锁：一般用在整表数据迁移的场景
每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；一般用在整表数据迁移的场景。myisam,innodb支持表锁。
加了读锁，无法进行写操作。所有session都可以进行读。
加了写锁，当前session可以进行增删改查，其它session无法对该表进行增删改查

行锁
每次操作锁住一行数据。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高。
InnoDB与MYISAM的最大不同有两点：
a.InnoDB支持事务（TRANSACTION）,myisam不支持
b.InnoDB支持行级锁,myisam不支持
打交道最多的是行锁

2.锁总结：
MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁,在执行update、insert、delete操作会自动给涉及的表加写锁。InnoDB在执行查询语句SELECT时(非串行隔离级别)，不会加锁。但是update、insert、delete操作会加行锁。
简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。
3.锁优化建议
1.尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
2.合理设计索引，尽量缩小锁的范围
3.尽可能减少检索条件范围，避免间隙锁。
4.尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
5.尽可能低级别事务隔离

间隙锁概述
间隙锁用于防止幻读现象，它锁住的是索引中记录之间的“间隙”，而不是记录本身。具体来说，当一个事务需要对某个范围的记录进行修改时，InnoDB 会锁住这个范围内的所有间隙，以防止其他事务插入符合条件的新记录。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数
据，这种现象就称为“幻读”。

行锁与事务隔离级别案例
略。

InnoDB引擎底层存储和缓存原理
当我们想从表中获取某些记录时，InnoDB 存储引擎需要一条一条的把记录从磁盘上读出来么？
InnoDB 采取的方式是：将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位，InnoDB 中页的大小一般为 16 KB。也就是在一般情况下，一次最少从磁盘中读取 16KB 的内容到内存中，一次最少把内存中的 16KB 内容刷新到磁盘中。

InnoDB记录存储结构和索引页结构（微观角度查看记录和页面存储方式）
1.记录存储结构（1条记录=1行数据）
2.索引页结构（索引页中包含了记录User Records）

InnoDB的体系结构（宏观角度查看InnoDB 的内存结构和磁盘存储结构）
1.内存结构
包含Buffer Pool、Redo Log Buffer
简化版
Buffer Pool（用于缓存磁盘中的页）
a.InnoDB 为了缓存磁盘中的页，在 MySQL 服务器启动的时候就向操作系统申请了一片连续的内存，他们给这片内存起了个名，叫做 Buffer Pool（中文名是缓冲池）。那它有多大呢？这个其实看我们机器的配置，默认情况下 Buffer Pool 只有128M 大小。它是可以配置的。
b.Buffer Pool 的缺省值其实是偏小的，一个比较合理的设置方法是按比例设置，一般的网上惯例是给 buffer pool 设置的机器内存的 60%-80%左右。以比较权衡的值是 70%~75%之间。具体值可以看服务器使用情况。
c.Buffer Pool 内部组成
1.Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是16KB。innodb会为每一个缓存页创建一些控制信息，控制信息包括该页所属的表空间编号、页号、缓存页在 Buffer Pool 中的地址、链表节点信息、一些锁信息以及 LSN 信息，当然还有一些别的控制信息。
每个缓存页对应的控制信息占用的内存大小是相同的，我们称为控制块。控制块和缓存页是一一对应的，它们都被存放到 Buffer Pool 中，其中控制块被存放到 Buffer Pool 的前边，缓存页被存放到 Buffer Pool 后边
2.free 链表的管理：用于标识哪些缓存页是空闲的，方便判断缓存存放。
3.LRU 链表的管理

2.磁盘结构
A.包含系统表空间、Redo Log、独立表空间、其他表空间、Undo空间
a.系统表空间（存储系统相关表文件数据（如innodb数据字典）、双写缓冲区等）
1),整个MySQL进程只有一个系统表空间
2)在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面，相当于是表空间之首，所以它的表空间 ID（Space ID）是 0。
系统表空间有extent 1和extent两个区，也就是页号从64~191这128个页面被称为Doublewrite buffer，也就是双写缓冲区。
b.独立表空间（存储每个业务表数据）
1).表空间中的页可以达到2的32次方个页，实在是太多了，为了更好的管理这些页面，
InnoDB中还有一个区（英文名：extent）的概念。对于16KB的页来说，连续的64个页就是一个区，也就是说一个区默认占用1MB空间大小。不论是系统表空间还是独立表空间，都可以看成是由若干个区组成的，每256个区又被划分成一个组。
所以结构由小到大为：页->区->组>表空间
2)如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O。如果两个页是相邻的，则为顺序I/O。随机I/O是非常慢。
引入区的主要目的是什么？（按区分为空间的话，分配的页大多是相邻的）
因为一个区是物理位置上连续的64个页，如果按区分为空间的话，分配的页大多是相邻的，从性能角度看，可以消除很多的随机I/O，可以更多的使用顺序I/O。
3).段（segment）可以将叶子节点和非叶子节点进行分类放在不同段，提升查询效率。它是一个逻辑概念。
B.表空间(tablespaces)是一个抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件，一般是（ibdata1）
C.对于每个独立表空间（也就是File-Per-Table Tablespaces）来说，对应着文件系统中一个名为表名.ibd的实际文件。
D.可以把表空间想象成被切分为许许多多个页的池子，当我们想为某个表插入一条记录的时候，就从池子中捞出一个对应的页来把数据写进去。
E.表空间中的每一个页都对应着一个页号，这个页号由4个字节组成，也就是32个比特位，所以一个表空间最多可以拥有2的32次方个页，如果按照页的默认大小16KB来算，一个表空间最多支持64TB的数据。

3.双写缓冲区和buffer pool的区别？
（作用不一样。双写缓冲区用于保证数据可靠性，用于写磁盘数据的恢复。当数据写入失败时可以通过它来恢复。而Buffer pool是为了缓存数据页Page信息。）
双写缓冲区是InnoDB存储引擎的一个特性，它用于保证数据的一致性和可靠性。当InnoDB引擎写入数据时，会先将数据写入到双写缓冲区，然后再写入到磁盘上的数据文件。如果在写入数据文件时发生了故障，可以通过双写缓冲区中的数据进行恢复，从而保证数据的一致性和可靠性。
Buffer pool是InnoDB存储引擎的另一个重要缓存区，它用于缓存数据页。当InnoDB引擎需要读取数据时，会先在buffer pool中查找数据页，如果找到了就直接返回，如果没有找到就从磁盘上读取数据，并将数据页存储到buffer pool中。当InnoDB引擎需要写入数据时，也是先将数据写入到buffer pool中，然后再异步地将数据写入到磁盘上的数据文件中。
因此，双写缓冲区和buffer pool的区别在于它们的作用不同，双写缓冲区用于保证数据的一致性和可靠性，而buffer pool用于缓存数据页，提高数据的读取和写入性能。
缓冲区不仅在内存中有，更多的是属于MySQL 的系统表空间，属于磁盘文件的一部分。

4.innodb doublewrite buffer和redo log区别？
（都属于系统表空间。redo log用于事务失败的恢复，而doubewrite buffer用于写磁盘数据的恢复）
innodb doublewrite buffer和redo log都是InnoDB存储引擎中用于保证数据完整性的机制，但它们的作用不同。
redo log是用于崩溃恢复的机制，记录了事务在执行过程中对数据所做的修改（此时还未存库），以便在崩溃后进行恢复。
doublewrite buffer是用于保证数据页写入磁盘的完整性的机制，它会在数据页写入磁盘之前，先将数据页的副本写入doublewrite buffer中，然后再将数据页写入磁盘。这样即使在写入磁盘的过程中发生了崩溃，也可以通过doublewrite buffer中的数据来恢复数据页，保证数据的完整性。
因此，redo log和doublewrite buffer都是InnoDB存储引擎中非常重要的机制，但它们的作用不同，各自都有其独特的作用。

innodb引擎底层事务实现机制
MVCC与BufferPool缓存机制
A.MVCC机制(用于保证事务隔离)
同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。这里就用到mvcc机制。mvcc机制全称多版本并发控制隔离机制(Multi-Version Concurrency Control)。
undo日志版本链与read view机制详解
1.undo即回滚，用于事务回滚。redo即重做，用于事务的崩溃恢复（比如机器宕机）。
2.undo日志版本链包含了日志信息和指针数据。
3.undo日志版本链的回滚指针是指向上一条日志。即它是较新的数据，指向的是旧的数据。
4.read-view即查询一致性视图
5.事务内，查询是不会生成事务id的，更新的时候才会生成事务id。
6.read- view在事务开始后的第一次查询时会生成一次，直到结束都不会变，其作用范围是本次事务。而undo日志版本链是会一直变的，只要有更新就会变，其作用范围是针对所有事务。

mvcc如何保证在其它事务修改了数据之后保证可重复读的？
答案是readview视图+undo日志版本链比对规则

B.BufferPool机制流程（提高读写性能）
1.mysql undo日志、redo日志、binlog的区别？
a.MySQL中有三种不同的日志文件类型：undo log、redo log和binlog。它们各自有不同的用途和特点。
undo log：用于回滚事务。当一个事务需要回滚时，MySQL会利用undo log中的信息将数据恢复到事务开始之前的状态。undo log是InnoDB存储引擎层的日志。
redo log：用于恢复事务。当MySQL崩溃并重新启动时，它会利用redo log中的信息将数据恢复到崩溃之前的状态。redo log是InnoDB存储引擎层的日志。
binlog：用于复制和恢复。binlog记录了所有对数据库的修改操作，包括对表结构的修改。它可以用于数据备份、恢复和复制。binlog是MySQL Server层记录的日志。
它们的区别可以总结如下：
用途：undo log用于回滚事务，redo log用于恢复事务，binlog用于复制和恢复。
存储位置：undo log和redo log都是InnoDB存储引擎层的日志，而binlog是MySQL Server层记录的日志。
记录内容：undo log记录了事务执行前的数据，用于回滚事务；redo log记录了事务执行后的数据，用于恢复事务；binlog记录了所有对数据库的修改操作，包括对表结构的修改。
格式：undo log和redo log的格式相同，都是物理日志；binlog的格式是逻辑日志。
日志生成：undo log和redo log是在事务执行时生成的；binlog是在事务提交时生成的。
删除策略：undo log和redo log的删除策略是循环利用；binlog的删除策略是根据过期时间删除。

物理日志和逻辑日志的区别？
物理日志 和 逻辑日志 主要在记录方式和用途上有所区别：
物理日志：记录数据页的实际变化。它们关注数据的具体物理状态或位置，更侧重于如何恢复数据的一致性和可靠性。
逻辑日志：记录数据的操作或事件，如 sql。它关注数据的变化内容和操作步骤，适用于主从复制、数据审计和恢复操作。

2.总结：即undo log和redo log和事务相关，属于引擎层的日志。undo log用于事务回滚，redo log用于由于系统宕机后为“事务提交成功，但未来得及写磁盘”的事务进行事务恢复。而binlog为server层日志，记录的所有数据库的sql操作，用于数据备份、恢复、复制。

Redo 日志和 Undo 日志的关系？
数据库崩溃重启后，需要先从 redo log 中把未落盘的脏页数据恢复回来，重新写入磁盘，保证用户的数据不丢失。当然，在崩溃恢复中还需要把未提交的事务进行回滚操作。由于回滚操作需要 undo log 日志支持，undo log 日志的完整性和可靠性需要 redo log 日志来保证，所以数据库崩溃需要先做 redo log 数据恢复，然后做 undo log 回滚。
在事务执行过程中，除了记录 redo 一些记录，还会记录 undo log 日志。Undo log 记录了数据每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log 进行回滚操作。
因为 redo log 是物理日志，记录的是数据库页的物理修改操作。所以 undo log（可以看成数据库的数据）的写入也会伴随着 redo log 的产生（因为undo log也是存储在数据库页中的，所以对undo log的操作也是对数据库页的物理操作），这是因为 undo log也需要持久化的保护。也就是说掉电重启的时候，会从redo log中，将redo log里的undo log数据恢复到undo log中。然后才会根据需要读取undo log进行回滚。
即对undo log的操作记录也会记录到redo log中同时写 Redo 和 Binlog 。怎么保持一致？（使用2PC）
略。

总的来说，MySQL 中事务的原子性是通过 undo log 来实现的，事务的持久性是通过 redo log 来实现的，事务的隔离性是通过读写锁+MVCC 来实现的。事务的一致性通过原子性、隔离性、持久性来保证。也就是说 ACID 四大特性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证一致性，数据库提供的手段。数据库必须要实现 AID 三大特性，才有可能实现一致性。同时一致性也需要应用程序的支持，应用程序在事务里故意写出违反约束的代码，一致性还是无法保证的，例如，转账代码里从 A 账户扣钱而不给 B账户加钱，那一致性还是无法保证。

在事务的具体实现机制上，MySQL 采用的是 WAL（Write-ahead logging，预写式日志）机制来实现的。这也是是当今的主流方案。(即所有修改先写日志再写磁盘)
1.在使用 WAL 的系统中，所有的修改都预先被写入到日志中，然后再被应用到系统中。通常包含redo 和 undo 两部分信息。
2.redo 日志：准确的说是修改日志，而不是失败重做日志。

MySQL 事务执行流程
MySQL 的事务主要主要是通过 Redo Log 和 Undo Log 实现的。
MySQL 在事务执行的过程中，会记录相应 SQL 语句的 UndoLog 和Redo Log，然后在内存中更新数据并形成数据脏页。接下来 RedoLog 会根据一定规则触发刷盘操作，Undo Log 和数据脏页则通过刷盘机制刷盘。事务提交时，会将当前事务相关的所有 Redo Log 刷盘，只有当前事务相关的所有 Redo Log 刷盘成功，事务才算提交成功。

MySQL事务恢复流程
如果一切正常，则 MySQL 事务会按照上图中的顺序执行。如果 MySQL 由于某种原因崩溃或者宕机，当然进行数据的恢复或者回滚操作。
如果事务在执行第 8 步,即事务提交之前，MySQL 崩溃或者宕机,此时会先使用Redo Log 恢复数据,然后使用 Undo Log 回滚数据。
如果在执行第8步之后MySQL崩溃或者宕机，此时会使用Redo Log恢复数据，大体流程如下图所示。

MySQL 崩溃恢复后，首先会获取日志检查点信息，随后根据日志检查点信息使用 Redo Log 进行恢复。MySQL 崩溃或者宕机时事务未提交，则接下来使用 Undo Log 回滚数据。如果在 MySQL 崩溃或者宕机时事务已经提交，则用Redo Log 恢复数据即可。

恢复机制
在服务器不挂的情况下，redo 日志简直就是个大累赘，不仅没用，反而让性能变得更差。但是万一数据库挂了，就可以在重启时根据 redo 日志中的记录就可以将页面恢复到系统崩溃前的状态。
MySQL 可以根据 redo 日志中的各种 LSN 值，来确定恢复的起点和终点。然后将 redo 日志中的数据，以哈希表的形式，将一个页面下的放到哈希表的一个槽中。之后就可以遍历哈希表，因为对同一个页面进行修改的 redo 日志都放在了一个槽里，所以可以一次性将一个页面修复好（避免了很多读取页面的随机 IO）。
并且通过各种机制，避免无谓的页面修复，比如已经刷新的页面，进而提升崩溃恢复的速度。

事务崩溃后的恢复为什么不用 binlog？
1、这两者使用方式不一样
binlog 会记录表所有更改操作，包括更新删除数据，更改表结构等等，主要用于人工恢复数据，而 redo log 对于我们是不可见的，它是 InnoDB 用于保证crash-safe 能力的，也就是在事务提交后 MySQL 崩溃的话，可以保证事务的持久性，即事务提交后其更改是永久性的。
一句话概括：binlog 是用作人工恢复数据，redo log 是 MySQL 自己使用，用于保证在数据库崩溃时的事务持久性。
2、redo log 是 InnoDB 引擎特有的，binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
3、redo log 是物理日志，记录的是“在某个数据页上做了什么修改”，恢复的速度更快；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2这的 c 字段加 1 ” ；
4、redo log 是“循环写”的日志文件，redo log 只会记录未刷盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。binlog 是追加日志，保存的是全量的日志。
5、最重要的是，当数据库 crash 后，想要恢复未刷盘但已经写入 redo log 和binlog 的数据到内存时，binlog 是无法恢复的。虽然 binlog 拥有全量的日志，但没有一个标志让 innoDB 判断哪些数据已经入表(写入磁盘)，哪些数据还没有。
比如，binlog 记录了两条日志：
给 ID=2 这一行的 c 字段加 1
给 ID=2 这一行的 c 字段加 1
在记录 1 入表后，记录 2 未入表时，数据库 crash。重启后，只通过 binlog 数据库无法判断这两条记录哪条已经写入磁盘，哪条没有写入磁盘，不管是两条都恢复至内存，还是都不恢复，对 ID=2 这行数据来说，都不对。
但 redo log 不一样，只要刷入磁盘的数据，都会从 redo log 中抹掉，数据库重启后，直接把 redo log中的数据都恢复至内存就可以了。

从架构师层面做mysql调优
1.mysql优化大方向来讲从下到上主要分为3个方面：架构调优、mysql调优、硬件和os调优。
越往上走，难度越来越高，收益却是越来越小。
2.从MySQL执行全流程考虑性能优化