InnoDB 存储引擎中的锁.

1、锁的类型

InnoDB 存储引擎 lock 的对象是事务，用来锁定的是数据库中的对象，如表、页、行，而且通常 lock 的对象仅在事务 commit 或 rollback 后进行释放（不一样事务隔离级别释放的时间可能不一样）。

InnoDB 存储引擎实现了以下两种标准的行级锁，其中，X 锁与任何的锁都不兼容，而 S 锁仅和 S 锁兼容（兼容指对同一记录行的兼容性状况）

• 共享锁（S Lock），容许事务读一行数据；
• 排他锁（X Lock），容许事务删除或更新一行数据；

InnoDB 存储引擎除了行锁之外，还有表锁，一般也称为意向锁，其设计目的主要是为了在一个事务中揭示下一行将被请求的锁类型。其支持两种意向锁：

• 意向共享锁（IS Lock），事务想要得到一张表中某几行的共享锁
• 意向排他锁（IX Lock），事务想要得到一张表中某几行的排他锁

经过 information_schema 架构下的 INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS 三张表，用户能够更简单的监控当前事务并分析可能存在的锁问题。

SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

2、锁的算法

InnoDB 存储引擎有三种行锁的算法，其分别是：

• Record Lock：单个行记录上的锁
• Gap Lock：间隙锁，锁定一个范围，但不包含记录自己
• Next-Key Lock：Record Lock + Gap Lock，锁定一个范围，而且锁定记录自己

Record Lock 老是会去锁住索引记录，InnoDB 存储引擎会使用聚簇索引来进行锁定。

Gap Lock 的做用是为了阻止多个事务将记录插入到同一个范围内，由于这会致使幻读问题（phantom Problem）的产生，用户能够经过如下两种方式来显式地关闭 Gap Lock：

• 将事务的隔离级别设置为 READ COMMITTED
• 将参数 innodb_locks_unsafe_for_binlog 设置为 1

Next-Key Lock 是结合了 Gap Lock 和 Record Lock 的一种索引算法，这种锁定技术，不止锁定记录自己，还锁定一个范围。

InnoDB 对于行的查询默认是采用 Next-Key Lock 算法，当查询的索引含有惟一属性时（主键索引、惟一索引），InnoDB 存储引擎会对 Next-Key Lock 进行优化，将其降级为 Record Lock；而对于辅助索引，不只会对索引列加 Record Lock ，还会对索引列先后的键值范围加上 Gap Lock。

Phantom Problem：幻读问题，指在同一事务下，连续执行两次一样的 SQL 语句可能致使不一样的结果，第二次的 SQL 语句可能会返回以前不存在的行。

1. 聚簇索引的加锁状况

select * from students where id = 20  for update;

2. 惟一索引的加锁状况

select * from students where num = 135 for update;

3. 二级索引的加锁状况

select * from students where score= 91  for update;

4. 无索引的加锁状况

select * from students where age = 22  for update;

3、锁的问题

1. Dirty Read 脏读：一个事务读到了另外一个未提交的事务写的数据，这显然违反了数据库的隔离性。

2. Non-Repeatable Read 不可重复读：一个事务内屡次读取同一数据集合，可能两次读到的数据是不同的。不可重复读和脏读的区别是：脏读是读到未提交的数据，而不可重复读读到的倒是已经提交的数据，这显然违反了数据库的一致性。

3. Phantom Problem 幻读 ：幻读问题，指在同一事务下，连续执行两次一样的 SQL 语句可能致使不一样的结果，第二次的 SQL 语句可能会返回以前不存在的行。幻读是比不可重复读高一个级别的错误，读取同一条数据发现跟刚才是同样的，只有读取一堆数据发现突然多了一个，或者少了一个，像是产生了幻觉。

4. Lost Update 更新丢失
   a. 第一类更新丢失，回滚覆盖：撤消一个事务时，在该事务内的写操做要回滚，把其它已提交的事务写入的数据覆盖了。
   b. 第二类更新丢失，提交覆盖：提交一个事务时，写操做依赖于事务内读到的数据，读发生在其余事务提交前，写发生在其余事务提交后，把其余已提交的事务写入的数据覆盖了。这是不可重复读的特例。

为了解决多个事务并发会引起的锁问题，数据库系统提供了四种事务隔离级别供用户选择。

• Read Uncommitted 读未提交：不容许第一类更新丢失。容许脏读，不隔离事务。
• Read Committed 读已提交：不容许脏读，容许不可重复读（即容许第二类更新丢失）。
• Repeatable Read 可重复读：不容许不可重复读（即不容许第二类更新丢失），但可能出现幻读。
• Serializable 串行化：全部的增删改查串行执行。

为何 MYSQL 默认使用 Repeatable Read 隔离级别？这跟数据库的主从复制有关，MYSQL 的主从复制是基于 binlog 复制的，而 binlog 有三种格式，分别为：

• statement：记录的是修改 SQL 语句
• row：记录的是每行实际数据的变动
• mixed：statement 和 row 模式的混合

那 MYSQL 在 5.0 这个版本之前，binlog 只支持 statement 这种格式！而这种格式在读已提交（Read Commited）这个隔离级别下主从复制是有 bug 的，所以 Mysql 将可重复读（Repeatable Read）做为默认的隔离级别。

怎么解决 Read Committed 隔离级别下，主从复制有问题的 bug？首先得解释下这个 bug，在 master 上执行的顺序为先删后插，若此时 binlog 为 statement 格式，它记录的顺序为先插后删，slave 同步的是 binglog，所以 slave 执行的顺序和主机不一致，就会出现主从不一致，怎么解决这个 bug 呢？

1. 隔离级别设为可重复读（Repeatable Read），在该隔离级别下引入间隙锁（GAP LOCK），在执行 DELETE 语句时，会锁住间隙，那么执行 INSERT 语句就会阻塞住。
2. 将 binglog 的格式修改成 row 格式，此时是基于行的复制，天然就不会出现 sql 执行顺序不同的问题（这个格式在 MYSQL 5.1 版本才开始引入）。

4、其它

1. 在 InnoDB 存储引擎中，参数 innodb_lock_wait_timeout 用来控制等待得时间（默认是 50 秒），innodb_rollback_on_timeout 用来设定是否在等待超时时对进行中的事务进行回滚操做（默认是 OFF，表明不回滚）

2. InnoDB 存储引擎在大部分状况下都不会对异常进行回滚（死锁除外），所以用户必须判断是否须要 COMMIT 仍是 ROLLBACK，以后再进行下一步的操做。

3. InnoDB 存储引擎经过 wait-for graph（等待图）的方式来进行死锁检测，wait-for graph 是一种较为主动的死锁检测机制，在每一个事务请求锁并发生等待时都会判断是否存在回路，若存在则有死锁，一般来讲 InnoDB 存储引擎选择回滚 undo 量最小的事务。

4. InnoDB 存储引擎不存在锁升级的问题，由于其不是根据每一个记录来产生行锁的，相反，其根据每一个事务访问的每一个页对锁进行管理的，采用的是位图的方式。所以无论一个事务锁住页中的一个记录仍是多个记录，其开销一般是一致的。