事务：锁和并发
什么是事务？
单个事务
- 商品建立一个基于GMT_Modified的索引
- 从数据库中读取一行记录
- 向数据库中写入一行记录，同时更新这行记录的所有索引
- 删除整张表
- Etc...
以上都属于一个事务单元，从请求发起，到数据库更新数据段或者读出数据，刷完log之后，都在一个事务单元之中。
什么是ACID？
A：原子性(Atomic)
即最终成功或者最终全部失败。一个事务要么同时成功，要么同时失败。不能存在中间状态。
C：一致性(Consistency) (Happen Before的关系)
两个事务同时发生时，保证事务单元全部结束后才可见。
I：隔离性(Isolation)
以性能为原由，对一致性的破坏。
序列化读写(排它锁)，保证了严格的一致性，但性能和效率严重不足。
将所升级为 读写锁 ，即支持可重复读(REPEATABLE READ)。读锁不能被写锁升级。即不能做到读写并行，读读可以并行。但不能在有读锁时候对写放开。
几个隔离级别：
- 读已提交(Read Commited)
读写可以并行。(版本号，即时间戳的一种)，将读锁升级成写锁 - 读未提交(Read UnCommited)
读未提交，写读并行时候，可能造成读取到写未写完的状态。 - 可重复读
读读可以并行。 - 序列化读
完全串行的读，性能太差。 - 隔离性扩展
快照隔离级别(Snapshot Isolation)即MVCC(多版本并发控制)
核心思路：
- copy on write
- 无锁编程
核心做法：
多版本读
写时(版本1)，并行读undo操作(版本0)
D：持久性(Durability)
只要事务完成以后，该事务对数据的更改将持久保持在数据库中。
磁盘I/O速度原因可以使用：
RAID
什么是MVCC？
多版本并发控制。
MVCC适合读写比率比较高的场景。
如何进行故障恢复？
通过Binlog，记录undo日志。在数据库启动时候，一段时间内不能对外提供服务。即这时候进行恢复数据。
通过回滚段，加锁。保证单位时间内只有一个人操作。
commit 标志整个事务是否完成。如果有未提交的commit，则通过回滚段进行roll back。commit之后，则继续完成剩余步骤。
recovery的过程应当是原子的，也需要保证ACID。
死锁以及死锁检测
- 尽量不死锁
- 碰撞检测
- 等锁超时
关于锁的优化
减少锁的范围，即减小锁的颗粒度：
从表锁 -> 行锁
MVCC -> 原子锁
增加锁上可并行的线程数量。
选择正确的锁类型：
悲观锁 在并发争抢比较严重的情况
乐观锁
使用两种锁的判别标准，目前数据争抢是否严重。
MVCC适合读写比率比较高的场景，如果写较多的话，则需要记录相当多的undo日志。
