上一节《查询语句的执行顺序》总体梳理了一下mysql中查询语句的执行顺序，这次梳理一下mysql的修改语句的执行顺序
其实修改语句的执行顺序跟查询语句的顺序一样，
1:连接器-处理链接，验证权限
2:查询缓存-缓存失效，所以不建议在修改频繁的表上用查询缓存
3:分析器-词法分析，语法分析，验证否和mysql的标准
4:优化器-选择用那个id查询符合条件的数据
6:执行器-校验表权限，调用执行引擎，返回结果
mysql的server层有binLog
innoDB的执行引擎有redoLog
log文件系统是一个非常经典的设计模式
举个例子，孔乙己所在的咸亨饭店，有很多人赊账，掌柜的很忙的时候，不会直接记一笔赊账记录在账本里面，而是在柜台上的小黑板上记下这次赊账的记录，然后在空闲的时候，再把小黑板上的记录转记到账本里面。这个小黑板的功能，就相当于redoLog
InnoDB的这项优化技术叫WAL。write-ahead-logging.先写日志，再写磁盘。如果mysql出现的异常，之前的操作都会在内存redoLog中和磁盘中，这中能力叫crash-safe。
不过InnoBD的小黑板很大，可以分为4个，每个黑板1G大小，像个循环链表，从头开始写，写到末尾，会把开头的记录写到硬盘里买呢，然后空余的空间写新的操作记录。
InnoDB的redoLog实现了crash-safe能力，但是InnoDB只是Mysql的一个执行引擎，其余的执行引擎可能没有redoLog。所以Mysq在Server层也有自己的日志系统-binLog，binLog记录的是update的逻辑操作。
所以在执行update语句的时候，到底发生了什么呢
1:执行器执行update语句，引擎会先根据索引或者其余的筛选条件，把符合的结果集返回给执行器，
2：执行器获取的结果集数据，依次更新，然后调用执行引擎写入新的数据
3:执行引擎将数据更新到内存中，然后把更新操作写入redoLog，此时redolog记录是prepare状态，告诉执行器随时可以提交事物
4:执行器把这个update操作写入binLog，并写入磁盘
5:执行器调用执行引擎把刚才的redoLog的状态改为commit状态，更新完成。
很有意思的问题，redoLog和binLog到底有什么不同呢