本章内容:
- 事务特性
- redo log如何实现持久性
- undo log如何实现原子性
- 锁+MVCC 实现隔离性
事务特性
- A:Atomic,原子性,即事务中的操作要么全部完成,要么全部失败
- C:Consistent,一致性,靠其他三大特性支持
- I:Isolation,隔离性,事务之间不能相互影响
- D:Durability,持久性,即commit操作完成后,事务对数据库的修改就该有效;
- 主要是修改操作是先修改内存中的数据拷贝,以后才刷新回磁盘中,所以如果这时服务器宕机,修改就丢失了
redo log如何实现持久性
实现:innodb通过Force Log at Commit机制实现持久性
- 即提交事务时,必须必须把事务所有修改操作写入redo log文件,之后提交才算完成
- innodb启动时,会检查是否需要进行恢复操作
性能影响:redo log包括两部分(内存中的重做日志缓冲区、磁盘中的重做日志文件),重做日志缓冲会先写入到文件系统的缓存里的,必须得fsync系统调用才写回文件
补充:innodb允许用户手动设置非持久化来提高性能
- 修改操作不是每次都直接写入redo log文件中的,会先写入redo log缓冲中,再通过fsync系统调用把缓冲刷入文件中持久化
- innodb_flush_log_at_tri_commit控制每几次事务刷一次
undo log
作用:回滚(保证原子性)+MVCC
实现:记录事务修改操作,遇到ROLLBACK或异常时,查看日志来进行反操作
分类:
- insert undo log:插入数据只对本事务可见(RR解决了幻读),提交后即删除
- update undo log:用于MVCC,放入undo log链表中等待purge线程删除
- 哪些undo log可删除:不会被活跃事务再访问,比如说如果有两个已提交事务对某数据修改,那先提交的那个undo log就可以删除了
注:回滚是逻辑回滚,物理结构可能变化;undo log操作也会产生redo log,也需要持久化
redo和undo的区别
redo undo 用处 保证持久性 回滚、MVCC 存储位置 redo log文件 undo段(数据结构) 物理日志(往哪个页写、删) 逻辑日志(sql) undo log的回滚操作也会写入redo
数据库实现AID三大特性后,才有可能实现一致性