事务由来
假设A与B账号都有10元,A账号转给B账号5元,这时A账号还剩5元,服务器忽然停电或者其他问题导致系统崩溃,B账号却没有成功收到转来的5元。(我们都知道,在对页进行读写时,不会立即刷到磁盘,而是加载到buffer pool,在某个时间点,才会刷新到磁盘)
如何解决这个事情呢?
我们要保证数据库每个操作都要符合原子性、隔离性、一致性、持久性,这些操作称为事务
事务特性
- 原子性
要么全成功,要么全失败的规则称为原子性,不可能出现中间态情况,一半成功,一半不成功。
原子性实现依赖于undo日志,进行回滚 - 隔离性
不管你多少次操作,都互相之间不影响彼此操作,称为隔离性
隔离性实现依赖于MVCC与加锁实现 - 一致性
如果数据库中数据全部符合现实世界中业务场景的约束,那我们称为这这些数据是一致的,符合一致性规则
假设:有人说它高考成绩是1000分,你一听就是胡扯,不符合一致性。 - 持久性
就是把数据持久性保存在磁盘上,无法发生了什么事故,除非是磁盘坏了,数据都不会丢失。
持久性的实现依赖于redo日志记录。
事务并发执行时遇到问题
- 脏写
如果一个事务修改了另一个未提交事务修改过的数据,就意味着发生了脏写现象 - 脏读
如果一个事务读到了另一个未提交事务修改过的数据 - 不可重复读
同样的条件下,读取过的数据,当我们再次读取时值发生了变化。 - 幻读
同样的条件下,第1次和第2次读出来的记录数不一样
事务隔离级别
为了解决上面并发执行时,出现问题,设立一些隔离级别
- 读未提交
这种隔离级别,可能出现脏读、不可重复读、幻读 - 读已提交
这种隔离级别,可能出现不可记重复读、幻读 - 可重复读
这种隔离级别,可能出现幻读 - 串行化
原理加锁
MVCC
MVCC称为多版本并发控制,意思就是不加锁,可以处理事务并发带来问题
那么它的实现依赖于版本链与ReadView
- 版本链
每次update记录,就插入一条undo日志,串成一个链,被称为版本链 - readview
readview包括四个主要部分 m_ids、min_trx_id、max_trx_id、creator_trx_id
1)m_ids : 表示生成readview是,当前系统活跃的读写事务id列表,就是未提交事务列表id
2)min_trx_id:就是m_ids 中最小值
3)max_trx_id:系统应该分配给下一个事务id值
4)creator_trx_id:就是当前事务id
- readview 判断版本事务可见性规则
1.当前版本trx_id等于creator_trx_id 结论:可见
2.trx_id <min_trx_id 结论:可见
3.trx_id >max_trx_id 结论 :不可见
4.trx_id <min_trx_id<max_trx_id 时,如果trx_id 在m_ids中,不可见,否则可见