深度解读MySQL意向锁的工作原理机制与应用场景
意向锁
意向锁的概念
意向锁是InnoDB自动添加的一种锁，不需要用户去干预。
是数据库中的一种表级锁，一个事务要给一个资源加锁时，必须要先获取到对应类型的意向锁之后，才可以给这个资源加上自己想要的共享锁或者排他锁（不论是行级还是表级的共享/排他锁，都是需要先获取到意向共享/排他锁）。
意向锁并不是真正的锁，而是为了协调事务对表中行的锁定请求而引入的一个概念。
意向锁业的两个类型
意向共享锁（Intention Shared Lock，IS锁）: 表示事务有获取到表的表级或行级共享锁的意向。
意向排他锁（Intention Exclusive Lock，IX锁）: 表示事务有获取到表的表级或行级排它锁的意向。
注意：获取意向锁只是表示事务有获取到共享锁和排它锁的意向意图，而不是表示获取了意向锁，就是实际锁定了任何行或表。
意向锁是互相兼容的，不会互斥。
说明案例
前提：
如果事务A需要修改user表的id（有索引）为 ‘1’ 的数据行，则事务A会给这行数据加上一个行级排他锁，和一个意向排他锁。
场景一：
此时如果事务B想修改user表的name（无索引）为 ‘张三’ 的数据行，则事务B就需要给user表加上表级排他锁，但是在获取表级排他锁之前，还需要获取意向排他锁，然后就发现已经有事务A获取了意向排他锁，则事务B可以直接阻塞等待了，不再需要往下尝试判断能否获取到表级排他锁。
意向锁通过这种前置判断的操作，很好的解决了行锁与表锁共存时的事务隔离性问题。
场景二：
此时如果事务B想修改user表的id（有索引）为 ‘2’ 的数据行，则事务B就需要先获取意向排他锁，虽然此时事务A已经持有了user表的意向排他锁，但是事务B仍旧可以去获取user表的意向排他锁，因为 意向锁是互相兼容的，不会互相排斥 （上文也有说到），获取到意向排他锁之后，再去判断id为2的数据行是否有共享锁和排他锁，发现没有，则事务B持有到user表id为2的数据行的行级排他锁。
总结
行表头为事务A已经获取的锁
列表头为事务B能否获取的锁
| 意向共享锁 | 意向排他锁 | 表级共享锁 | 表级排他锁 | 行级共享锁 | 行级排它锁 | |
|---|---|---|---|---|---|---|
| 意向共享锁 | 兼容 | 兼容 | 兼容 | 不兼容 | 兼容 | 不兼容 |
| 意向排他锁 | 兼容 | 兼容 | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
| 表级共享锁 | 兼容 | 不兼容 | 兼容 | 不兼容 | 兼容 | 不兼容 |
| 表级排他锁 | 不兼容 | 不兼容 | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
| 行级共享锁 | 兼容 | 额外讨论-1 | 兼容 | 不兼容 | 兼容 | 同行不兼容 不同行兼容 |
| 行级排它锁 | 额外讨论-2 | 额外讨论-1 | 不兼容 | 不兼容 | 同行不兼容 不同行兼容 | 同行不兼容 不同行兼容 |
额外讨论-1
事务A获取了 意向排他锁 ，事务B能否获取 行级共享锁 或 行级排他锁 需要继续往下去判断，判断事务A的排他锁是表锁还是行锁，
如果是表锁，则事务B不能再加行级共享锁；
如果是行锁，则继续判断事务B要加行级共享锁的行是否被事务A或其他事务加了行级排它锁，如果加了，则事务B不能再加行级共享锁，如果这一行没加行级排他锁，则事务B可以加上行级共享锁（行锁：同行不兼容，不同行兼容）。
额外讨论-2
事务A获取了 意向共享锁 ，事务B能否获取 行级排他锁 需要继续往下去判断，判断事务A的共享锁是表锁还是行锁，
如果是表锁，则事务B不能再加行级排他锁；
如果是行锁，则继续判断事务B要加行级排他锁的行是否被事务A或其他事务加了行级共享锁，如果加了，则事务B不能再加行级排他锁，如果这一行没加行级共享锁，则事务B可以加上行级排他锁（行锁：同行不兼容，不同行兼容）。
关注我，我将持续输出Java常用相关技术文章。