MySQL事务实现 校招知识点总结

本章内容：

1. 事务特性
2. redo log如何实现持久性
3. undo log如何实现原子性
4. 锁+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

Innodb 锁实现事务隔离性

数据库实现AID三大特性后，才有可能实现一致性