上一节《查询语句的执行顺序》总体梳理了一下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到底有什么不同呢