前情提要
在简单认识了一下事务日志的框架之后， 我们需要做的是把整个流程窜起来， 先用个简单的例子。
案例 把id=1 的用户余额从100改成200
- 当执行更新操作的时候， innodb 会先把数据从磁盘读到内存的缓冲池。
- 先记录 undo log , 把 id =1 的用户余额 = 100 这个信息保存下来。
- 这样一来， 如果后面事务出错需要回滚， 就能通过这里的记录进行恢复。
- 接着引擎会在内存把这个账户的余额改成200 。
- 接着 记录redo log , 内容 大概是 "ID =1 的用户 的余额 改成 200 这个操作"
- 这样就算数据库突然崩溃， 内存里边的修改丢了， 重启后也能通过这个记录，重新执行一遍操作。
- 最后在整个事务提交的时候， mysql 会把这次的修改记录到binlog 了。内容同样是"ID =1 的用户 的余额 改成 200 这个操作"
- 服务器层面的日志，让从库知道 主库做了哪些修改
总结
- 记 undo log 备份回滚
- 管理范围 在 提交成功之前 ，崩溃了， 事务处于未提交的状态 出了问题 都回滚 就需要这个undo log
- 再记 redo log 保证持久性
- 管理范围 在提交成功之后 ，崩溃了， 事务处于已提交状态， 出了问题 就通过redo log 恢复数据
- 需要注意的是 在 事务提交过程中 redo log buffered（redo log 不是每次操作都刷 而是先记录到内存的buffered 批量刷新） 就会被强制刷到 磁盘 如果 刷失败了 也算提交失败
- 管理范围 在提交成功之后 ，崩溃了， 事务处于已提交状态， 出了问题 就通过redo log 恢复数据
- 最后事务提交 记 binlog 供同步。
补充
-
MyISAM存储引擎 没有undo log 或者 redo log 所以他不支持事务
-
存储引擎 可以理解为 Mysql的数据处理发动机，他负责怎么存储数据， 如何建立索引， 怎么处理事务。 设计成可插拔的存储引擎架构， 而不是自己一条龙昨晚， 主要是应对不同的业务需求。