mysql update 机制_【MySQL】一条update语句的生命周期

最近看到一个关于MySQL的面试题：一条update语句在MySQL中的生命周期是怎么样的？我觉得这个问题很有意义，看似简单，实际上考察的是对MySQL整个架构体系的一个理解。那么我们就来整理一下一条SQL在MySQL中的整个历程。

一、Server层阶段：连接器：首先当然是要跟MySQL服务端建立连接，那么连接器主要做的事情就是握手，建立连接工作线程，判断最大连接数，权限验证，和维持连接(循环)

分析器：对SQL进行语法分析，判断语句类型，是否存在语法错误，以及用户对表的访问权限

优化器：对SQL进行语句优化，选择索引，生成执行计划

执行器：根据优化器生成的执行计划，调用存储引擎的API执行SQL

二、存储引擎层(InnoDB)阶段：

事务执行阶段首先判断 update 语句涉及的数据页是否存在于 innodb buffer pool(BP) 中，如果不存在，则从磁盘中读取该行记录所在的数据页并加载到BP缓冲池中，具体加载过程：首先通过 space id 和 page no 哈希计算之后把索引页加载到BP中

然后判断BP中的 free list 是否有空闲可用，没有则需要通过 checkpoint 机制对 flush list 中的脏页进行刷盘或者将 lru list 的 old list 里面copy 数据页到 free list 中，并加载到 old list 的头部(midpoint)；通过二分法查找到该页对应要修改的记录，并加上排他锁(关于锁的又可以写一篇文章，这里简单说明下，加锁前会判断是否锁等待和死锁)

接着先写undo log，将修改前的记录写入undo log中，并写入事务id到这条记录，然后使用回滚指针指向undo log中的修改前的行，用于回滚数据和实现MVCC(关于MVCC又可以写一篇文章)

接着写redo log buffer：判断redo log buffer是否够用，不够用会等待，然后将记录在BP中进行update，并将修改后的字段值写入redo log buffer中，同时还会LSN加上当前redo log写入的长度(写入长度为length的redo log，LSN号就回加上length)。

接着写binlog cache：修改的信息，会以event的格式，记录到binlog cache中

接着写change buffer：将update语句对二级索引上做的修改，写入到 change buffer，等到下次有其他sql需要读取该二级索引的时候，再去与二级索引做merge(change buffer是innodb中的重要特性，主要还是对磁盘IO的优化，将随机IO转化为顺序IO)

到这里为止，数据在内存中就更新完成了，BP中对应的数据页也成了脏页。

事务提交阶段

事务的COMMIT分为prepare阶段与commit阶段。事务的COMMIT操作，在Server层和InnoDB引擎层之间采用的是内部XA；作用是为了保证redo log和binlog的原子性。

prepare阶段(redo)：

写入redo log处于prepare状态，并写入事务的xid；

将redo log buffer刷到redo log磁盘文件中，用于carsh recovery。(刷盘的方式由innodb_flush_log_at_trx_commit 参数决定)

commit阶段(binlog)：

binlog write&fsync：执行器将binlog cache里的完整事务和redo log prepare中的xid写入binlog中(在这一步，binlog cache里面的的event会由dump线程发给slave的I/O线程，同时执行fsync刷盘，然后清空binlog cache)

redo log commit：这里只是在redo log里标记commit

事务提交还会涉及到redo group commit 和 binlog group commit 就不在这里展开讲了，这个后面专门开一篇文章来分析。

到止，一条update语句的生命周期就结束了。