数据库系统原理

事务是指满足ACID特性的一组操作，可以通过commit提交事务，也可以通过rollback回滚

Atomicity(原子性)：事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。回滚可以用回滚日志(Undo log)实现

Consistency(一致性)：一个或多个事务执行后，原来一致的数据和数据库任然一致，主要涉及事务的原子性

Isolation(隔离性)：一个事务在提交前的所有修改对其他事务不可见

Durability(持久性)：一旦事务提交后，所做的修改将永远保存在数据库中，即使数据库发生崩溃，事务执行的结果也不能丢失。
                               系统发生崩溃可用重做日志(redo log)来恢复，从而保证数据持久性。与回滚日志记录的是逻辑数据的修改
                               不同，重做日志记录的是数据页的物理修改

产生并发不一致性问题的主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。并发控制可以通过封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题

一个事务的修改被另一个事务的修改所替换。例如：两个事务同时对一个数据修改，T1先修改并提交生效，T2随后修改，T2的修改覆盖了T1的修改

读脏数据是指当前事务读到了另一个事务还未提交的数据。例如：一个事务T1对数据进行修改，还未提交。另一个事务T2读到了修改后的数据，此时T1出现问题发生回滚，T2读到的就是脏数据

不可重复读是指在一个事务内多次读取同一数据集合，在这一事务还未结束前，另一个事务也访问了这个数据集合并做了修改，由于第二个事务的修改，第一个事务的两次读取结果可能不一致。例如：T1读取了数据，T2对该数据修改了,如果T1再读了此数据，此时读取结果和第一次读取结果可能不同

幻读本质上也属于不可重复读的情况。例如：T1读取了一个范围内的数据，T2在这个范围内插入了一条数据，如果T1再次读取这一范围内的数据，则与第一次读取的结果不一致

MySQL 中提供了两种封锁粒度：行级锁以及表级锁

选择封锁粒度策略

读写锁

意向锁

三级封锁协议

两段锁协议

隐式锁定

显示加锁

事务中的修改，即使未提交，对其他事务也是可见的

一个事务只能读取已经提交的事务所做的修改

保证在同一事务中，多次读取同一数据的结果是一致的

强制事务串行执行，这样多个事务互不干扰，不会出现并发一致性问题

在 MVCC 中事务的修改操作（DELETE、INSERT、UPDATE）会为数据行新增一个版本快照

脏读和不可重复读最根本的原因是事务读取到其它事务未提交的修改。在事务进行读取操作时，为了解决脏读和不可重复读问题，MVCC 规定只能读取已经提交的快照。当然一个事务可以读取自身未提交的快照，这不算是脏读

系统版本号SYS_ID

事务版本号TRX_ID

MVCC 的多版本指的是多个版本的快照，快照存储在 Undo 日志中，该日志通过回滚指针 ROLL_PTR 把一个数据行的所有快照连接起来

例子

MVCC维护了一个read view结构，主要存储未提交的事务列表{TRX_ID_1,TRX_ID_2,...}以及列表中事务id的最小值TRX_ID_MIN和最大值TRX_ID_MAX

在进行select时，根据当前事务id与TRX_ID_MIN和TRX_ID_MAX之间的关系来判断数据快照是否可用

当数据行快照不可使用时，需要沿着Undo Log的回滚指针ROLL_PTR找寻下一个快照，再进行上面的判断

快照读

当前读

MVCC不能解决幻读，在可重复读（REPEATABLE READ）隔离级别下，MVCC+Next-Key Loks可以解决幻影读的问题