MySQL实战学习(二)

redo log

当数据库有一条记录需要更新时,InnoDB引擎会先把记录写到redolog中,同时更新内存。这个时候就算是更新完成了,同时,InnoDB会在适当时刻将这个操作记录更新到磁盘里面。InnoDB 的 redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB,那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下面这个图所示。

当空间写满时,也就是写指针追上检查指针后,就要停下所有的更新操作,先擦除一部分数据,再把检查指针推进。

这个redolog可以保证数据库发生异常重启时,之前提交的记录不会丢失,这种能力叫做crash-safe

TIPS:CPU在进行复杂运算时会把中间数据存储到它的缓存中,而当CPU缓存满了的时候,缓存会与RAM进行数据同步,他们之间同过脏位dirty-bit来区分哪些数据需要进行更新,个人感觉思想上这两者差不多,同时我也了解一个一种缓存的更新策略,Write Behind Caching 更新模式。Write Back 套路就是,在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的 I/O 操作飞快无比(因为直接操作内存嘛)。因为异步,Write Back 还可以合并对同一个数据的多次操作,所以性能的提高是相当可观的。

binlog

对比一下两种日志有以下三点不同。

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

Binlog有两种模式,statement 格式的话是记sql语句, row格式会记录行的内容,记两条,更新前和更新后都有。

保证数据库的一致性,必须要保证2份日志一致,使用的2阶段式提交;其实感觉像事务,不是成功就是失败,不能让中间环节出现,也就是一个成功,一个失败