为什么需要 RedoLog? BufferPool 是随机 10 以页为单位,性能损耗很大,不可每次提交都同步刷盘,需要后续异步进行。不能 同步刷就会有一个问题,如果 MySQL 宕机,而事务已提交在 BufferPool 的数据还没有刷到磁盘,就会 导致数据丢失持久性无法保证。为此引入 RedoLog,这个文件 10 是顺序追加 10 且以修改为单位,性能 很高,每次事务提交持久化 RedoLog 到磁盘也不会对性能造成太大影响,如果宕机可以通过重启从 redoLog 恢复丢失数据。 RedoLog 高性能? 映射一段连续的存储空间,保证顺序 1O,数据先写入 Buffer,后一次性批量将事务数据写入磁盘。
下面咱们说说 InnoDB 锁机制(此处重点关注)。 为了控制事务并发时的数据安全,在不同隔离级别下会通过不同的协同机制进行处理。传统隔离机制, 完全由锁(LBCC)来处理,但是这样只能满足读读并发,会对性能造成很大影响,故而出现了支持读写并 单直接的列出 update、delete、insert 的加锁情况(RC 和 RR 不一样)。 Update & Delete 语句加锁 1)聚簇索引(查询命中)
UPDATE students SET score =| 100 WHERE id = 15;
X 锁 X 锁
Read Commited Repeatable Read
S0001 S0006 S0005 S0006 S0007 S0001 S0002 S0007 S0004 S0003 S0004 Alice Eric Bob Alice Jim Eric Tom Rose Rose Bob Tom Tom Tom
RC、RR 都是对聚簇索引加 X 锁。 注:RC 读已提交(READ COMMITTE)、RR 可重复读(REPEATABLE READ) 2)聚簇索引(查询未命中)
UPDATE students SET score = 100 WHERE id = 16;
Read Commited Repeatable Read
S0002 S0003 S0004 S0005 S0006 S0001 S0007 S0001 S0006 S0007 S0003 S0004 S0005 Eric Alice Alice Tom Tom Eric Tom Tom Bob Bob Rose
RC 不加锁,RR 在 16 之前和之后的范围里加 GAP 锁。 注:Gap 是问隙锁,在索引/记录之间的间隙中加锁,或者是在某一条索引记录之前或者之后加锁,并不 包括该索引记录本身。gap lock 的机制主要是解决可重复读模式下的幻读问题 3)二级唯一索引(查询命中)
UPDATE students SET score = 100