我们都是小青蛙文章------锁

type_mode是用于区分这个锁结构到底是行锁还是表锁，如果是表锁的话是意向锁、直接 对表加锁、还是AUTO-INC锁，如果是行锁的话，具体是正经记录锁、gap锁还是next-key锁。

InnoDB的行锁是与记录一一对应的。即使是对于gap锁来说，在实现 上也是为某条记录生成一个锁结构，然后该锁结构的类型是gap锁而已，并不是专门为某个 区间生成一个锁结构。该gap锁的功能就是每当有别的事务插入记录时，会检查一下待插入 记录的下一条记录上是否已经有一个gap锁的锁结构，如果有的话就进入阻塞状态。 

同一个事务，在同一个页面上加的相 同类型的锁都放在同一个锁结构里。

一条语句加什么锁受多种因素影响：

1. 事务的隔离级别
2. 语句执行时使用的索引类型（比如聚簇索引、唯一二级索引、普通二级索引）
3. 是否是精确匹配
4. 是否是唯一性搜索（如果在扫描某个扫描区间的记录前，就能事先确定该扫描区间最多只包含1条记录的话，那么就把 这种情况称作唯一性搜索。）
5. 具体执行的语句类型（SELECT、INSERT、DELETE、UPDATE）
6. 是否开启innodb_locks_unsafe_for_binlog系统变量
7. 记录是否被标记删除 

LOCK_S 表示加S 锁（比方说执行SELECT ... LOCK IN SHARE MODE时）， LOCK_X 表示加X锁（比方说执行 SELECT ... FOR UPDATE、DELETE、UPDATE时）。 

对于Repeatable Read隔离级别来说，只在首次执行SELECT语句时生成 Readview，之后的SELECT语句都复用这个ReadView；对于Read Committed隔离级别来 说，每次执行SELECT语句时都会生成一个ReadView。

语句加锁分析

 加锁 只是解决并发事务执行过 程中引起的 脏写 、 脏读 、 不可重复读 、 幻读 这些问题的一种解决方案（ MVCC 算是一种解 决 脏读 、 不可重复读 、 幻读 这些问题的一种解决方案）

普通的 SELECT 语句

1. READ UNCOMMITTED 隔离级别下，不加锁，直接读取记录的最新版本，可能发 生 脏读 、 不可重复读 和 幻读 问题。
2. READ COMMITTED 隔离级别下，不加锁，在每次执行普通的 SELECT 语句时都会生成一 个 ReadView ，这样解决了 脏读 问题，但没有解决 不可重复读 和 幻读 问题。
3. REPEATABLE READ 隔离级别下，不加锁，只在第一次执行普通的 SELECT 语句时生成一 个 ReadView ，这样把 脏读 、 不可重复读 和 幻读 问题都解决了。
4. SERIALIZABLE 隔离级别下，需要分为两种情况讨论： 在系统变量 autocommit=0 时，也就是禁用自动提交时，普通的 SELECT 语句会被转 为 SELECT ... LOCK IN SHARE MODE 这样的语句，也就是在读取记录前需要先获得记录 的 S锁 ，具体的加锁情况和 REPEATABLE READ 隔离级别下一样，我们后边再分析。 在系统变量 autocommit=1 时，也就是启用自动提交时，普通的 SELECT 语句并不加锁，只 是利用 MVCC 来生成一个 ReadView 去读取记录。 为啥不加锁呢？因为启用自动提交意味着一个事务中只包含一条语句，一条语句也就没有 啥 不可重复读 、 幻读 这样的问题了。

 InnoDB 中的 MVCC 并不能完完全全的禁止 幻读。

 锁定读的语句

捏麻麻滴，太多了，不想看了，摆烂........