一条更新语句的执行流程又是怎么样的呢?
更新流程除了上文书说到的分析器、优化器、执行器之外,还涉及到两个重要的日志模块:redo log(重做日志)和 binlog(归档日志)。孔乙己赊账的例子
redo log
WAL(Write-Ahead Logging)技术
先写日志,再写磁盘!
redo log 文件 ib_logfile_n
Innodb 引擎特有的日志功能。配置 redo log 为固定大小,比如 4 块,每个大小 1G,共可记录 4G,循环利用。
crash-safe
write pos 是写入的位置,checkpoint 是要擦除的位置,擦除前要将记录更新到数据文件中。write pos追上 checkpoint 时停止更新,先擦掉一些再推进 checkpoint。有了这个功能在 InnoDB 异常时记录不丢失。
binlog
redo log 是 InnoDB 独有的日志功能,在 Server 层有自己的日志称为归档日志 binlog。在没有 InnoDB 的时候用 binlog 实现 crash-safe 的能力。
两种日志的不同点
- redo log 是 InnoDB 独有,binlog 是 Server 层实现,所有引擎共用。
- redo log 是物理日志,记录数据页上的修改;binlog 是逻辑日志,记录原始语句。
- redo log 是循环写入,空间需要回收擦除;binlog 是可以追加写入,不会覆盖。
Update语句流程
两阶段提交
将 redo log 的写入拆成两个步骤,先 prepare 再 commit 这就是 两阶段提交。目的是为了让两个日志保持逻辑一致。
小结
物理日志redo log 和 逻辑日志 binlog
my.cnf 配置,每次事务的 redo log 直接持久化到磁盘,保证异常重启不丢失
innodb_flush_log_at_trx_commit = 1
my.cnf 配置,每次事务的 binlog 直接持久化到磁盘,保证异常重启不丢失
sync_binlog = 1
根据业务需要,选择全量备份的频率。