更新的SQL语句是如何执行的？

一、redolog

当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log（粉 板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后掌柜做的事。
InnoDB 的redo log是固定大小的。比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。

write pos是当前记录的位置，checkpoint是当前要擦除的位置，write pos和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。
redolog用于保证crash-safe 能力。innodb_flush_log_at_trx_commit这个参数设置成 1 的时候，表示每次事务的 redolog 都直接持久化到磁盘。这个参数我建议你设置成 1， 这样可以保证 MySQL 异常重启之后数据不丢失。

二、binlog

binlog会记录所有的逻辑操作，并且是采用“追加写”的形式。如果你 的 DBA 承诺说半个月内可以恢复，那么备份系统中一定会保存最近半个月的所有 binlog，同时系统会定期做整库备份。这里的“定期”取决于系统的重要性。
binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
binlog不能被去掉的原因

• redolog只有InnoDB有，别的引擎没有。
• 另一个原因是，redolog是循环写的，不持久保存，binlog的“归档”这个功能，redolog是不具备的

sync_binlog 这个参数设置成 1 的时候，表示每次事务的binlog都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog不丢失。

三、binlog和redolog的区别

• redolog是InnoDB引擎特有的。binlog是MySQL的Server 层实现的，所有引擎都可以使用。
• redolog是物理日志，记录的是“在某个数据页上做了什么修改”。binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”
• redolog是循环写的，空间固定会用完。binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

四、两阶段提交

指的是redolog的准备阶段和提交阶段。

• 在修改数据到内存
• 写redolog，处于准备阶段
• 写binlog，并且持久化到磁盘
• 提交事务，处于提交阶段

两阶段提交的主要原因是为了让日志之间的逻辑一致。
不一致可能导致的问题

• 先写redolog后写binlog：恢复数据的时候可能少一条记录
• 先写binlog后写redolog：恢复数据的时候可能多一条记录

五、update语句的内部流程

• 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁 盘读入内存，然后再返回。
• 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
• 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redolog 里面，此时redolog 处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
• 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
• 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状 态，更新完成