前言
mysql 的表锁之 AUTO_INC, 是我们自增长的时候做并发控制的锁
主要是用于 自增长生成新的 id 的时候的控制
在前面的文档中, 我们又看到 mysql 这边自增长的处理的相关的大概脉络
但是 对于一些 并发控制的细节, 我们当时 应该是直接忽略掉了
我们这里就来看一下 mysql 这里的 AUTO_INC 的一个实现
当然 它的实现 有几种方式, 模式选择有 0, 1, 2
模式为 0 的场景下, 主要是 基于乐观锁, 每一个表映射一个 mutex, 来尝试乐观获取锁
模式为 1 的场景下, 对于 INSERT, REPLACE 命令主要是 基于乐观锁, 每一个表映射一个 mutex, 来尝试乐观获取锁, 其他的场景基于 表自增长锁
模式为 2 的场景下, 主要是基于和前面的 表共享锁, 表排他锁 一个级别的 表自增长锁
我们这里核心关注的是 表自增长锁 的相关实现
表自增长锁
获取 LOCK_AUTO_INC 这边的实现 和 获取其他表级别的锁的主流程一致
差异在于 LOCK_AUTO_INC 和其他锁的兼容性, 在之前 表共享锁, 表排他锁 的场景下面, 为了简化问题, 我们是跳过了 LOCK_AUTO_INC, 这里我们来讲 LOCK_AUTO_INC 代入进来看看
从这里可以看到, 如果是我们 LOCK_AUTO_INC 这边和 表意向锁 是兼容的
和 LOCK_AUTO_INC 是不兼容的, 和 表共享锁, 表排他锁 是不兼容的
总结下来意思就是, 如果是 事务1 获取的是 行锁, 那么是不影响 事务2 获取 表自增长锁 的
如果是 事务1 获取的是 表自增长锁, 那么是会阻塞 事务2 获取 表自增长锁 的
如果是 事务1 获取的是 表共享锁, 表排他锁, 那么是会阻塞 事务2 获取 表自增长锁 的
整体的这边获取 表自增长锁 这边的具体的 锁表策略 分派方式如下
基本上三种策略就是 mutex乐观锁 + mutex乐观锁, 表自增长锁 + 表自增长锁
表自增长锁的获取和释放
表自增长锁 的获取是在执行 insert sql 的时候
然后释放 表自增长锁 是在语句执行完成之后释放的 如下
表自增长锁阻塞的 N 中方式
表自增长锁 的阻塞方式 就是上面提及的 表共享锁, 表排他锁, 表自增长锁 被持有的情况下
假设我们这里尝试模拟 各种阻塞的方式, 事务1先进行执行, 然后事务2尝试获取表排他锁, 产生阻塞
事务2 这边执行固定的 sql 语句如下
begin;
INSERT INTO `test_02`.`tz_test_02`(`field1`, `field2`) VALUES ('field1', '11');
commit;
事务1获取 表排他锁 导致 事务2获取MDL元数据锁 阻塞
begin;
lock tables tz_test_02 write;
-- sleep 10min
unlock tables;
commit;
事务1获取 表共享锁 导致 事务2获取MDL元数据锁 阻塞
begin;
lock tables tz_test_02 read;
-- sleep 10min
unlock tables;
commit;
事务1 获取了 表自增长锁, 导致事务2获取MDL元数据锁 阻塞
完