02 一条sql更新语句如何执行？

crash-safe：

redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。

过程

1、连接器：权限验证

2、查询缓存。是否命中。（表有更新的话，和这个表有关的查询缓存会失效，这是不建议使用查询缓存的原因）

3、分析器:词法分析，语法分析

4、优化器：执行计划生成，索引选择。

5、执行器先通过搜索主键索引或者辅助索引找引擎取 ID=2 这行所在的数据页。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

5.1 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

5.2 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。

5.3 然后告知执行器执行完成了，随时可以提交事务。执行器生成这个操作的 binlog，并把 binlog 写入磁盘。

5.4 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

补充：如何通过索引查找，群组提交。5.3中undolog如何被标记可删除,update的内部机制是什么?
binlog是不是乱序的，redolog是不是乱序的。
宕机之后：

PS ：

两阶段提交：

1、redo  log刷盘，innodb的prepare将事务状态设为TRX_PREPARED
2、SQL语句写到binlog，此时，事务已经铁定要提交了。
3、innobase_hton->commit则清除undo信息，刷redo日志，将事务设为commit状态。

binlog 组提交：

将有关联性的多个数据修改操作放在一个事务中，这样可以避免对每个修改操作都执行完整的持久化操作。
将多个事务涉及到的binlog一次性flush，而不是每次flush一个binlog。
将事务按序放入一个队列，队列中的第一个事务称为leader，其他事务称为follower，leader控制着follower的行为。

flush阶段：向内存中写入每个事务的二进制日志。
sync阶段：将内存中的二进制日志刷盘。若队列中有多个事务，那么仅一次fsync操作就完成了二进制日志的刷盘操作。
commit阶段：leader根据顺序调用存储引擎层事务的提交，由于innodb本就支持group commit，

在flush阶段写入二进制日志到内存中，但是不是写完就进入sync阶段的，而是要等待一定的时间，多积累几个事务的binlog一起进入sync阶段，等待时间可以自己设定。

WAL技术：

Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

宕机

在重启mysql服务的时候，会检查事务日志的完整性。分3种情况：
1.在宕机之前或mysql停止之前，事务日志和数据已经全部刷到磁盘的redo log，说明事务日志是多余的，那么启动的时候，直接跳过事务日志的检查。
2.如果缺少事务日志文件，也会直接跳过事务日志的检查。这可能会导致重启前后数据的不一致。(数据页LSN大于redolog LSN,这个是因为刷盘的时候,)
3.事务日志没有刷完就宕机，也就是说，事务日志的文件是不完整的。（会回滚的。）

跳过日志检查:检查点会触发数据页和日志页刷盘，日志刷盘可能快于数据刷盘，也可能等于，还可能是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的：当数据刷盘速度超过日志刷盘时，将会暂时停止数据刷盘，等待日志刷盘进度超过数据刷盘。