第六章 事务

事务由来

假设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中，不可见，否则可见