Mysql执行流程图（精选）

Buffer Pool缓存池

page cache

即时写入

未提交事务和已提交事务

100

InnoDB存储引擎

BinLog Buffer

BinLog文件

4、写入redo日志

语法词法分析

redoLog Buffer

日志写磁盘流程

InnoDB SQL执行流程

client执行sql（id为1的数据name原值为tx）update t_user set name='Rick' where id = 1;

undo日志文件（InnoDB）name=tx

rick02

8、随机写入磁盘，以Page为单位写入，磁盘数据就变更成Rick

5、准备提交事务，将Redo日志写入磁盘

pagename=tx

后台IO线程

6、准备提交事务，将数据写入Binlog文件

7、写入commit标识到Redo文件，提交完成，保证Redo和Binlog两者一致

参数0

Server层

1

200

参数n

300

执行器

900

undo日志版本链

用户空间

Binlog日志文件（Server层持有）name=Rick

后台线程每秒写入

操作系统决定

Redo日志文件（InnoDB）name=Rick

DB_TRX_ID

物理磁盘

redo log文件

600

管理连接与权限校验

Redo Log Buffer

如果事务提交成功，但是Buffer Pool数据还没有写入磁盘，系统宕机了，可以使用Redo日志里面的数据恢复到Buffer Pool。（顺序写）

max_id = 900

700

400

DB_ROLL_PTR

3、更新内存数据

800

RedoLog 和 BinLog 并不是直接实时写入磁盘，中间还有一个页缓存，用来提升写入读取速度（页缓存是在内核空间，属于特殊的内存空间）

rick04

数据库的增删改查都是直接操作Buffer Pool，一般设置Buffer Pool为机器内存的60%左右

Redo日志是顺序写，循环写，文件大小固定，写满就重头开始写，覆盖原来的内容，断电后可以用来恢复事务数据，但是不可作为整库数据恢复（因为数据被覆盖过）小贴士：每条 redo 记录由“表空间号+数据页号+偏移量+修改数据长度+具体修改的数据”组成BinLog是顺序写，达到限制后，会切换到下一个文件继续写，断电后可作为整库恢复binlog记载的是update/delete/insert这样的SQL语句

即时调用fsync()刷盘

磁盘文件（idb）

1000

未开始事务

执行计划生成与索引选择

连接器

已提交事务

2、写入旧值到undo日志，方便回滚

后台线程每秒调用fsync()刷盘

rick03

内核空间

id

参数2

Binlog是Server层的日志，所有的MySQL存储引擎都支持Binlog。Binlog可以支持主从复制和数据恢复，但是对事务的ACID特性支持比较差。InnoDB存储引擎引入RedoLog和UndoLog事务日志，用于提升事务场景下的数据库性能

500

name

rick01

分析器

如果事务提交失败，需要回滚数据，可以用undo日志里面的数据恢复到Buffer Pool。（随机写）

优化器

n次事务后调用fsync()刷盘

1、加载id=1记录所在的整页数据到Buffer缓存池（如果缓存中有该数据，则这一步不需要）

Binlog主要用来做恢复数据库磁盘里面数据的。（顺序写）

read-view包含如下信息视图数组：[400， 700， 800] min_id：400max_id：900 

当前最新记录

调用执行引擎

pagespan style=\

RR级别下：事务开启后，首次查询会生成一致性视图read-view，该视图在事务结束之前都不会变化RC级别下：事务开启后，每次查询都会重新生成新的read-viewread-view视图由查询时所有未提交事务trx_id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果版本链比对规则：1、trx_id<min_id，表示这个trx_id已经提交了，这个数据是可见的2、trx_id>max_id，表示这个trx_id还没有生成（未来生成），这个数据是不可见的3、min_id <= trx_id <= max_id，如果trx_id在视图数组中，表示是未提交的事务，则是不可见的；否则是已经提交的事务，是可见的注：1、begin/start transaction 命令并不是一个事务的起点，执行第一个增删改操作时，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id2、事务id生成是全局顺序的，但undo日志版本链里面的事务ID并不是顺序的，左图只是方便查看，才将事务id做成顺序的3、删除操作可以认为是特殊update，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据4、事务开启与观察的表的版本链没有关系，比如你观察的是account表的版本链，但是事务开启是因为user表做了更新操作（后面才做account表的更新操作）

InnoDB刷盘策略数据（脏页）刷盘span class=\"hljs- 系统内存不足时，需要将一部分数据页淘汰掉，如果淘汰的是脏页，需要先将脏页同步到磁盘；- MySQL 认为空闲的时间，这种情况没有性能问题；- MySQL 正常关闭之前，会把所有的脏页刷入到磁盘，这种情况也没有性能问题。- redo log 日志满了的情况下，会主动触发脏页刷新到磁盘Redo Log日志InnoDB引擎有一个后台线程，每隔1 秒，就会把 redo log buffer 中的内容写到文件系统缓存（page cache），然后调用 fsync 刷盘。也就是说，一个没有提交事务 redo log 记录，也可能会刷盘。commit刷盘策略由innodb_flush_log_at_trx_commit来控制。0：提交事务时，不进行刷盘操作。提交成功，数据库或者服务器宕机会导致丢失1秒钟的数据1：提交事务时，span style=\

参数1

pagename=tx -> name=Rick

DB_ROW_ID

1100

min_id = 400