[TOC]
image.png
为什么C等待拿锁之后，D也会阻塞？其实这里并没有解释清楚。因为如果按并发理解的话，C，D应当是同等级，都有可能拿到锁的。但C读写锁互斥，D读读不互斥，这样的话就跟上图所述相悖了。就，查了一下。
首先是MDL（metaData Lock）的概念。元数据锁是server层的锁，表级锁，主要用于隔离DML（Data Manipulation Language，数据操纵语言，如select）和DDL（Data Definition Language，数据定义语言，如改表头新增一列）操作之间的干扰。每执行一条DML、DDL语句时都会申请MDL锁，DML操作需要MDL读锁，DDL操作需要MDL写锁（MDL加锁过程是系统自动控制，无法直接干预，读读共享，读写互斥，写写互斥）
image.png
申请MDL锁的操作会形成一个队列，队列中写锁获取优先级高于读锁。一旦出现写锁等待，不但当前操作会被阻塞，同时还会阻塞后续该表的所有操作。事务一旦申请到MDL锁后，直到事务执行完才会将锁释放。（这里有种特殊情况如果事务中包含DDL操作，mysql会在DDL操作语句执行前，隐式提交commit，以保证该DDL语句操作作为一个单独的事务存在，同时也保证元数据排他锁的释放，例如id 44的语句改为<begin;alter table testok add z varchar(10) not Null;select * from testok;>，此时一旦alter语句执行完成会马上提交事务（autocommit=1），后面的select就在本次事务之外，其执行完成后不会持有读锁）
这样就能解释通为什么session C被阻塞后，session D也运行不了的原因了。
然后进入下一个问题：
image.png
我也试了一下，确实如此，加上begin之后，session D会“插队”到session C前面，也就是原本的队列结构竟然出现了 “插队”现象，？？？
这个问题就要涉及到online ddl了。
由于ddl读写互斥，严重影响性能，于是mysql推出了全新的online ddl概念，即通过：
- 拿MDL写锁
- 降级成MDL读锁
- 真正做DDL
- 升级成MDL写锁
- 释放MDL锁
5个步骤，第一步拿读锁是为确保没有其他ddl语句在执行；第三步是自己申请一块空间开始改表结构、填数据；等填好了之后，执行第四步，这期间由于持有读锁，可以确保不会有其他ddl语句造成不一致性；最后等拿到写锁，把表一替代就搞定了。
这样就看出来端倪了。上图中session A，Bcommit后，sessionC确实拿到了写锁，只不过由于锁降级，令sessionD拿到了读锁。但session D没有commit，因此session C在执行online commit到第三步后，又给阻塞了。所以就出现了类似于“插队”的现象。
如果想验证的话，可以再开一个begin;select...的session，就叫sessionE吧。然后让刚刚没commit的session D commit一下，会发现这次session C并没有阻塞
image.png
网友评论