MySQL -update语句流程总结

废话很少说先来张图解释

update T set value = value+1 where ID =2
复制代码

我想可能大部分人看完这图，思考片刻，接下来的就不须要在继续看了，可是考虑到部分朋友仍是新手（包括本身）以及后面复习，仍是稍微唠叨一段。

update过程

首先，上图中深色背景的表示在执行器中执行，也就是Server层，浅色的是在InnoDB引擎中执行。
因为不少朋友并非专业的DBA或者对MySQL内部原理并非特别清晰，因此先对redolog和binlog作简单的介绍。

• redolog

  重作日志，属于物理日志，上面存储的是数据库中最终的内容，有固定的大小，能够循环读写，通常设置innodb_flush_log_at_trx_commit为1，表示commit事务时将redolog上面的数据刷入到磁盘（具体的能够自行研究redolog file 和redolog buffer）。具备两个状态分别是prepare和commit，在MySQL重启恢复时会根据commit状态恢复数据。

• binlog

  归档日志，属于逻辑日志，上面存储的是最初的修改逻辑能够简单的理解为sql语句，能够追加写，通常设置sync_binlog为1，表示commit事务时将binlog上面的数据刷入到磁盘进行归档。数据恢复和同步都是经过binlog来实现的。

下面以文字的方式再次描述一下update T set value = value+1 where ID =2的过程。

1. 词法分析器识别出事update语句；
2. 执行器去InnoDB中进行查询，找到知足ID = 2 的数据；
3. 执行器将value的值加1；
4. 执行器让InnoDB将刚刚的新值写入到InnoDB的内存中；
5. InnoDB在redolog中加入一条记录，并把该记录的状态设置为prepare；
6. 执行器经“update T set value = value+1 where ID =2” 写入到binlog中；
7. 此时提交事务，将redolog中prepare的的记录状态设为commit，而且将内存中的新数据刷入磁盘。

以上就是比较简单的过程理解，那么为啥要分开写redolog呢？即传说中的两阶段提交？这里再作个简单的分析。

首先对这种方式的好处作个总结：保证以上全部的过程若是出现MySQL实例奔溃都不会致使事务的丢失或异常。

接下来分析一下这么作的具体缘由：

1. 若是是第5步以前crash，就是还没写任何日志，那么事务就不存在，在恢复后从redolog和binlog中都不会有任何的问题；
2. 若是写完redolog 的prepare出现了crash，那么恢复时，经过redolog和binlog的对比，会发现只要一个prepare的日志，那么会将事务进行回滚，保证redolog和binlog的统一；
3. 若是写完binlog后出现crash，那么恢复时，会进行根据binlog日志对redolog进行补偿，对redolog以前prepare的记录修改成commit状态，事务获得保证；
4. 最后commit后crash，redolog和binlog都是正常的。

redolog只出如今InnDB中，并且是循环写的，不能持久保存，因此暂时不能用redolog来作主从或者数据备份

以上的是总结了不少博客和书上的内容，并非彻底的原创，本身也是在整理，但愿你们能指正不对之处。