mysql锁系列之MDL元数据锁之三

基础材料：

centos7.5  mysql 5.7.24

---

前一篇说明了元数据锁的相关加锁顺序，今天再结合online DDL更深入的研究一下这个加锁顺序究竟如何。

这里先简单说明一下online DDL锁升降级的过程，大体分为三步：

1、准备阶段：将申请到的SHARED_UPGRADABLE读锁升级为EXCLUSIVE写锁。禁止读写。

2、执行阶段：将EXCLUSIVE写锁降级成SHARED_UPGRADABLE读锁。期间可读写。

3、提交阶段：将SHARED_UPGRADABLE读锁升级为EXCLUSIVE写锁。禁止读写。

---

下面进行一个实验，用来毁三观，将<mysql锁系列之MDL元数据锁之一>中的实验改为如下，将id 45做成事务，不提交：

id 41	id 42	id 43	id 44	id 45
	begin；	begin；	alter table testok add z varchar(10) not Null;	begin;
	select * from testok limit 1;	select * from testok limit 1;		select * from testok;

 

 

 

 

 此时提交id 42，43，后会发现id 45的语句执行完了，id 44仍然被卡住等待EXCLUSIVE写锁，和开始一样一点没变。话说之前写的可是，写锁优先，且阻塞后续操作的啊，为啥id 45先执行了，44没动，这是不是有问题？

首先说明前面说的加锁规则并没有问题，当id 42,43执行完成后，id 44确实执行了，会在准备阶段拿到EXCLUSIVE写锁，此时id 45被pending。但在id 44执行阶段会进行锁降级，同为读锁，则id 45可以获取该锁，且持有该锁。当id 44运行到了提交阶段，要进行锁升级，此时需要等待id 45的读锁释放，被pending。观察的直观现象就是id 45执行完了，id 44好像没动。

如果id 45 执行的是lock tables testok read;select ....lock in share mode;select...for update则表现的情况与上面相同。

如果id 45 执行的是lock tables testok write;则id 44先执行完成并提交，id 45使用排他锁锁住该表。

如果id 45 执行的是alter table xxx，则id 45一直等待id 44的SHARED_UPGRADABLE锁释放，直到id 44执行完成。