MySQL中一些经典场景

1.联合索引的最左匹配原则碰到范围查询会失效：例如a,b，在a为单值时候，b是有序的可以走索引，但如果a是范围查询例如a>2，多段之间的b不是有序的，不能走索引。

2.做DDL时候，申请写锁，拿到后获取表结构信息；降级为读锁；后台做修改操作；读锁升级为写锁，替换老的表结构信息；释放DDL锁。

3.意向锁（IS，IX）是表级锁，意向锁之间都不互斥，意向锁和表级锁S，X之间存在兼容互斥，注意：意向锁和行锁不存在互斥关系！

4.merge过程并没有刷脏页：从磁盘读取老的数据页到内存；将change buffer中相关记录重放到数据页中；将数据的变更和change buffer的变更记录到redo log中。

5.两阶段提交如何保证一致性？如果在redo log的prepare阶段，还未写入bin log就回滚；如果在写完bin log，还未完成redo log的commit：如果redo log有commit标志就提交，如果redo log没有，检查bin log是否完整：statement格式的有commit标志，rowid格式的观察xid（mysql有bin log的校验和参数保证能验证bin log是否完整）。

6.单一bin log不具有崩溃恢复的能力，bin log记录的内容是逻辑上：例如对a=1这一行a+1，他没有记录具体数据页上的操作，而行数据在数据页（物理，地址）上随着update是变动的。

7.间隙锁只在rr级别有。间隙锁在主键以及二级索引上都会有。一定要记住锁是加载索引上的。

8.在rc级别下bin log使用row格式，也可以纠正幻读的问题，row格式对操作进行规则化改写。

9.rc级别的一个优化：语句执行过程中加上的行锁，语句执行完后（事务未提交），把不满足条件的行的行锁释放了，这是优化，不满足两阶段锁协议。

10.rr级别的一致性视图在for update语句时不会产生。

11.只读事务不会分配trx id，不存在视图。mvcc实现中高低水位判断事务可见性时候，不需要管只读事务，减轻了负担。