MySQL实战45讲 - 日志系统：一条SQL更新语句是如何执行的？
更新语句的逻辑前面是和查询语句一样的，查询语句的那一套流程，更新语句也是同样会走一遍。与查询流程不一样的是，更新流程还涉及两个重要的日志模块，redo log（重做日志）和 binlog（归档日志）
1、redo log
redo log（重做日志）是InnoDB存储引擎独有的。它是一种基于磁盘的数据结构，用于在故障恢复期间纠正由不完整事务写入的数据。
当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面（刷盘），而这个更新往往是在系统比较空闲的时候做。
InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。
并不是直接写入到了 redo log 中，是先写入了 log buffer 中
1.1、Log buffer
为了解决磁盘速度过慢的问题而引入了Buffer Pool。同理，写入 redo log时也不能直接直接写到磁盘上，所以引入了Log buffer。Log buffer(日志缓冲区)是保存要写入磁盘上日志文件的数据的内存区域，Log buffer可通过变量innodb_log_buffer_size配置，默认是16M。Log buffer的数据会定期的刷新到磁盘中，增加日志缓冲区大小可以支持大型事务，这样无需在事务提交之前将redo log写入磁盘，节省磁盘I/O，
1.2、redo log 刷盘时机
可能触发刷盘的操作有下面几种
- 当前写入 log buffer 的 redo log量已经占满了log buffer 总容量的大约一半左右，就需要刷盘
- 事务提交时
innodb_flush_log_at_trx_commit
- 当设置该值为1时，每次事务提交都要做一次刷盘，这是最安全的配置，即使宕机也不会丢失事务；也是默认值
- 当设置为2时，则在事务提交时只做写操作，只保证写到系统的page cache，因此实例崩溃不会丢失事务，但宕机则可能丢失事务；
- 当设置为0时，事务提交不会触发redo写操作，而是留给后台线程每秒一次的刷盘操作，因此实例崩溃将最多丢失1秒钟内的事务。
- 默认每秒都会刷新一次log buffer中的redo log到磁盘（变量
innodb_flush_log_at_timeout可以控制后台线程的刷新频率）
1.3、redo log 参数
- innodb_log_group_home_dir：修改redo log生成目录，默认为当前数据目录所在文件夹下
- innodb_log_file_size：单个redo log文件的大小，默认是48M
- innodb_log_files_in_group：redo log文件组的文件个数，默认是2，最大100
2、binlog
3、两阶段提交
两阶段提交主要是指的 redo log 的两阶段提交，两阶段提交是为了让两份日志（redo log 和 binlog）之间的逻辑一致。
两阶段提交的过程
1 | 更新语句为例子 |
- 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
- 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
- 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
<>两阶段提交的必要性
4、redo log 和 binlog 的不同
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；
binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。 - redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。