关于mysql:不能再简单的意向锁

InnoDB 存储引擎反对多粒度锁（multiple granularity locking），也就是容许行锁和表锁共存。当容许行锁和表锁共存的时候，可能会存在上面这样一个问题：

例如我执行如下 SQL：

这段 SQL 执行实现后，给 id 为 1 的记录加了排他锁。

此时，在另外一个会话中，我如果想给这张表再来一个表级共享锁，如下：

lock table user read;

此时就会有一个问题，共享锁和排他锁是互斥的，要给表上共享锁，就得去检查一下表中的每一条记录都不存在排他锁，如果表中的数据量比拟大，这个操作效率就会比拟低。

为了解决这个问题，就引出了咱们明天的意向锁。为了使多粒度级别的锁定变得实用，InnoDB 应用了意向锁，留神， 意向锁是一种表级锁 ，它示意事务稍后对表中的行须要哪种类型的锁（共享或独占）。

意向锁也分为两类：

1. intention shared lock：动向共享锁 (IS) 示意事务打算在表中的各个行上设置共享锁。
2. intention exclusive lock：动向排他锁 (IX) 示意事务打算对表中的各个行设置排他锁。

例如，对于 SELECT ... LOCK IN SHARE MODE; 会主动设置 IS 锁，对于 SELECT ... FOR UPDATE 会主动设置 IX 锁，并且 IS 锁和 IX 锁不须要手动设置，这个是由零碎主动设置。

意向锁的加锁规定如下：

• 在事务能够获取表中行的共享锁之前，它必须首先获取表上的 IS 锁或更强的锁。
• 在事务能够获取表中行的排他锁之前，它必须首先获取表上的 IX 锁。

简而言之：IS 和 IX 是表锁，它们存在的意义在于，未来给表上表级的 S 锁或者 X 锁的时候，能够通过 IS 或者 IX 疾速判断出以后表中是否曾经有加锁记录了，仅此而已。 所以 IS 和 IX 之间其实是兼容的，IX 之间也是兼容的 ，如下表：

然而意向锁和表级锁则有可能抵触，如下：

下面这张表也好了解：

• 如果表上有 IS，阐明表中的记录有共享锁，此时就不能够给表加排他锁（X 锁），然而能够给表加共享锁（S 锁）。
• 如果表上有 IX，阐明表中的记录有排他锁，此时就不能够给表加排他锁（X 锁），也不能够给表加共享锁（S 锁）。

整体上来说，兼容关系如下表：

因为意向锁并不需要咱们手动增加，那么有没有方法让咱们看到意向锁呢？能够的。

首先咱们将零碎变量 innodb_status_output_locks 设置为 ON，如下：

接下来咱们执行如下 SQL，锁定一行数据，此时会主动为表加上 IX 锁：

接下来咱们在一个新的会话中执行如下指令来查看 InnoDB 存储引擎的状况：

show engine innodb status\G

输入的信息很多，咱们重点关注 TRANSACTIONS，如下：

能够看到：

• TABLE LOCK table test08.user trx id 3564804 lock mode IX：这句就是说事务 id 为 3564804 的事务，为 user 表增加了动向排他锁（IX）。
• RECORD LOCKS space id 851 page no 3 n bits 80 index PRIMARY of table test08.user trx id 3564804 lock_mode X locks rec but not gap：这个就是一个锁构造的记录，这里的索引是 PRIMARY，加的锁也是正儿八经的记录锁（not gap），因为索引是 PRIMARY，所以这里没有间隙锁，对于间隙锁，咱们下篇文章持续。

好啦，心愿明天这篇文章能让小伙伴们对意向锁有一个简略的认知。

参考资料：

1. https://dev.mysql.com/doc/ref…