本文基于源码版本5.7.14
水平有限，有误请谅解
笔者已经将加好MDL 获取过程和释放过程的版本放到了github如下：
https://github.com/gaopengcarl/percona-server-locks-detail-5.7.22
供参考
作者深入理解主从原理专栏
https://www.jianshu.com/nb/43148932
MySQL中MDL锁一直是一个比较让人比较头疼的问题，我们谈起堵塞一般更加倾向于InnoDB层的row lock（gap lock/next key lock/key lock），因为它很好理解也很好观察。而对于MDL Lock考虑就少一些，因为它实在不好观察，只有出现问题查看show processlist的时候，可以看到简单的所谓的‘Waiting for table metadata lock’之类的状态，其实MDL Lock是MySQL上层一个非常复杂的子系统，有自己的死锁检测机制。
大家一般说是不是锁表了很大一部分就和MDL Lock有关，可见的它的关键性和严重性，笔者也是根据自己的需求学习了一些，且没有能力阅读全部的代码，但是笔者通过增加一个TICKET的打印函数让语句的MDL Lock加锁流程全部打印出来方便学习，下面从一些基础概念说起然后告诉大家笔者是如何做的打印功能，最后对每种MDL TYPE可能出现的语句进行测试和分析。如果大家对基本概念和增加打印函数不感兴趣可直接参考第五部分语句加MDL Lock测试和分析，希望这些测试能够帮助到大家诊断问题。
刚好最近笔者遇到一次MDL Lock出现死锁的情况会在下篇文章中给出案例，本文只看理论。
#0 open_table_get_mdl_lock(thd=0x7fffd0000df0,ot_ctx=0x7fffec06fb00,
table_list=0x7fffd00067d8,flags=0,mdl_ticket=0x7fffec06f950)
at/root/MySQL5.7.14/percona-server-5.7.14-7/sql/sql_base.cc:2789
#1 0x0000000001516e17inopen_table(thd=0x7fffd0000df0,
table_list=0x7fffd00067d8,ot_ctx=0x7fffec06fb00)
at/root/MySQL5.7.14/percona-server-5.7.14-7/sql/sql_base.cc:3237
{ "ER_LOCK_DEADLOCK", 1213, "Deadlock found when trying to get lock; try restarting transaction" },
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
可以发现MDL Lock的死锁抛错和Innodb死锁一模一样，不同的只是‘show engine innodb status’没有死锁信息。我们主要研究的类型如下：
MDL_INTENTION_EXCLUSIVE(IX)
MDL_SHARED(S)
MDL_SHARED_HIGH_PRIO(SH)
MDL_SHARED_READ(SR)
MDL_SHARED_WRITE(SW)
MDL_SHARED_WRITE_LOW_PRIO(SWL)
MDL_SHARED_UPGRADABLE(SU)
MDL_SHARED_READ_ONLY(SRO)
MDL_SHARED_NO_WRITE(SNW)
MDL_SHARED_NO_READ_WRITE(SNRW)
MDL_EXCLUSIVE(X)
第五部分会对每种类型进行详细的测试和解释。
在MDL中MDL_KEY按照namespace+DB+OBJECT_NAME的方式进行表示，所谓的namespace也比较重要下面是namespace的分类：
本文我们主要对GLOBAL/SCHEMA/TABLE namespace进行描述，而对于COMMIT namespace是提交的时候会用到的如果遇到等待，状态为‘Waiting for commit lock’，一般为FTWRL堵塞COMMIT。可参考我的《深入理解MySQL主从原理》15节。其他namespace不做描述。
下面是源码注释：
/**
Helper struct which defines how different types of locks are handled
for a specific MDL_lock. In practice we use only two strategies: "scoped"
lock strategy for locks in GLOBAL, COMMIT, TABLESPACE and SCHEMA namespaces
and "object" lock strategy for all other namespaces.
*/
这里兼容矩阵是学习锁堵塞的重点，类型很多比Innodb row lock类型要多很多，不用记住，只需要遇到能知道。
这个对应源码的enum_mdl_duration，通常我们需要关注MDL Lock是事务提交后释放还是语句结束后释放，实际上就是这个，这对MDL lock堵塞的范围很重要。我直接复制源码的解释。
使用两种不同的方式目的在于优化MDL Lock的实现，下面是源码的注释，可做适当了解：
也就是通过语句解析后需要获得的MDL Lock的需求，然后通过这个类对象在MDL子系统中进行MDL Lock申请，大概包含如下一些属性：
/** Type of metadata lock. */
enum enum_mdl_type type; //需求的类型
/** Duration for requested lock. */
enum enum_mdl_duration duration; //持续周期
/**
Pointers for participating in the list of lock requests for this context.
*/
MDL_request *next_in_list; //双向链表实现
MDL_request **prev_in_list;
/**
Pointer to the lock ticket object for this lock request.
Valid only if this lock request is satisfied.
*/
MDL_ticket *ticket; //注意这里如果申请成功(没有等待)，会指向一个实际的TICKET，否则为NULL
/** A lock is requested based on a fully qualified name and type. */
就是实际的namespace+DB+OBJECT_NAME，整个放到一个char数组里面，他会在MDL_LOCK和MDL_REQUEST中出现。
private:
uint16m_length;
uint16m_db_name_length;
charm_ptr[MAX_MDLKEY_LENGTH];//放到了这里
如同门票一样，如果获取了MDL Lock必然给MDL_request返回一张门票，如果等待则不会分配。源码MDL_context::acquire_lock可以观察到。部分属性如下：
/**
Pointers for participating in the list of lock requests for this context.
Context private.正如解释这里是context中链表链表的形成，是线程私有的
*/
MDL_ticket *next_in_context;
MDL_ticket **prev_in_context;
/**
Pointers for participating in the list of satisfied/pending requests
for the lock. Externally accessible.正如解释这里是MDL_LOCK中链表链表的形成，是全局的
*/
MDL_ticket *next_in_lock;
MDL_ticket **prev_in_lock;
/**
Context of the owner of the metadata lock ticket. Externally accessible.
很明显这里指向了这个ticket的拥有者也就是MDL_context，它是线程的属性
*/
MDL_context *m_ctx;
/**
Pointer to the lock object for this lock ticket. Externally accessible.
很明显这里是一个指向MDL_LOCK的一个指针
*/
MDL_lock *m_lock;
/**
Indicates that ticket corresponds to lock acquired using "fast path"
algorithm. Particularly this means that it was not included into
MDL_lock::m_granted bitmap/list and instead is accounted for by
MDL_lock::m_fast_path_locks_granted_counter
这里就代表了是否是FAST PATH从注释来看fast path方式不会在MDL LOCK中
占用granted位图和链表取而代之代之的是一个统计器m_fast_path_locks_granted_counter
这样一来开销肯定更小
*/
bool m_is_fast_path;
/**
Indicates that ticket corresponds to lock request which required
storage engine notification during its acquisition and requires
storage engine notification after its release.
*/
每一个MDL_key都会对应一个MDL_lock，其中包含了所谓的GRANTED链表和WAIT链表，考虑它的复杂性，可以直接参考源码注释也非常详细，这里给出我所描述的几个属性如下：
/** The key of the object (data) being protected. */
MDL_key key;
/** List of granted tickets for this lock. */
Ticket_list m_granted;
/** Tickets for contexts waiting to acquire a lock. */
Ticket_list m_waiting;
这是整个MySQL线程和MDL Lock子系统进行交互的一个所谓的上下文结构,其中包含了很多方法和属性，我比较关注的属性如下：
/**
If our request for a lock is scheduled, or aborted by the deadlock
detector, the result is recorded in this class.
*/
MDL_wait m_wait;
/**
Lists of all MDL tickets acquired by this connection.
这是一个不同MDL lock持续时间的一个链表数组。实际就是
MDL_STATEMENT一个链表
MDL_TRANSACTION一个链表
MDL_EXPLICIT一个链表
*/
Ticket_list m_tickets[MDL_DURATION_END];
//这是一个父类指针指向子类对象，虚函数重写的典型,实际他就指向了一个线程
/*
class THD :public MDL_context_owner,
public Query_arena,
public Open_tables_state
*/
MDL_context_owner *m_owner;
源码给出了所有的等待标记如下：
PSI_stage_info MDL_key::m_namespace_to_wait_state_name[NAMESPACE_END]=
{
{0, "Waiting for global read lock", 0},
{0, "Waiting for tablespace metadata lock", 0},
{0, "Waiting for schema metadata lock", 0},
{0, "Waiting for table metadata lock", 0},
{0, "Waiting for stored function metadata lock", 0},
{0, "Waiting for stored procedure metadata lock", 0},
{0, "Waiting for trigger metadata lock", 0},
{0, "Waiting for event metadata lock", 0},
{0, "Waiting for commit lock", 0},
{0, "User lock", 0}, /* Be compatible with old status. */
{0, "Waiting for locking service lock", 0},
{0, "Waiting for backup lock", 0},
{0, "Waiting for binlog lock", 0}
};
我们常见的是：
学习MDL Lock最好的方式当然是获取一条语句锁加的所有MDL Lock，包含加锁、升级、降级和释放的流程。虽然5.7加入诊断MDL Lock的方法：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl';
select * from performance_schema.metadata_locks
但是对于每个语句获取的所有MDL Lock的流程仍然不好观察，因此我加入了打印函数：
/*p_ticket in parameter*/
int my_print_ticket(const MDL_ticket* p_ticket)
并且在mdl_ticket类中增加了这个函数原型为友元函数：
friend int my_print_ticket(const MDL_ticket* p_ticket);
主要捕获MDL Lock的加锁信息打印到err日志中，包含的信息如下：
上面这些信息都在前面进行过描述了。具体的输出信息如下：
2017-08-03T07:34:21.720583Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T07:34:21.720601Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T07:34:21.720619Z 3 [Note] (-->MDL PRINT) OBJ_name is:test
2017-08-03T07:34:21.720637Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T07:34:21.720655Z 3 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T07:34:21.720673Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_WRITE(SW)
2017-08-03T07:34:21.720692Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
这实际上和metadata_locks中的信息差不多，如下：
MySQL> select * from performance_schema.metadata_locks\G
*************************** 1. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: test
OBJECT_NAME: test
OBJECT_INSTANCE_BEGIN: 140734412907760
LOCK_TYPE: SHARED_WRITE
LOCK_DURATION: TRANSACTION
LOCK_STATUS: GRANTED
SOURCE: sql_parse.cc:6314
OWNER_THREAD_ID: 39
OWNER_EVENT_ID: 241
一旦有了这个函数我们只需要在加锁、升级、降级和释放的位置进行适当添加就可以了。
既然我们要研究MDL Lock的加锁?升级?降级，那么我们就必要找到他们的函数入口，然后在合适的位置增加打印函数my_print_ticket进行观察，下面标示出打印位置。
bool
MDL_context::acquire_lock(MDL_request *mdl_request, ulong lock_wait_timeout)
{
if (mdl_request->ticket) //获取成功获得ticket
{
/*
We have managed to acquire lock without waiting.
MDL_lock, MDL_context and MDL_request were updated
accordingly, so we can simply return success.
*/
//REQUESET获取TICKET成功 此处打印
return FALSE;
}
/*
Our attempt to acquire lock without waiting has failed.
As a result of this attempt we got MDL_ticket with m_lock
member pointing to the corresponding MDL_lock object which
has MDL_lock::m_rwlock write-locked.
*/
//获取不成功加入MDL_lock 等待队列
lock= ticket->m_lock;
lock->m_waiting.add_ticket(ticket);
will_wait_for(ticket); //死锁检测
/* There is a shared or exclusive lock on the object. */
DEBUG_SYNC(get_thd(), "mdl_acquire_lock_wait");
find_deadlock();
//此处打印TICKET进入了等待流程
if (lock->needs_notification(ticket) || lock->needs_connection_check())
{
}
done_waiting_for();//等待完成对死锁检测等待图进行调整去掉本等待边edge(无向图)
//当然到这里也是通过等待后获得成功了状态为GRANTED
DBUG_ASSERT(wait_status == MDL_wait::GRANTED);
m_tickets[mdl_request->duration].push_front(ticket);
mdl_request->ticket= ticket;
MySQL_mdl_set_status(ticket->m_psi, MDL_ticket::GRANTED);
//此处打印通过等待REQUEST获得了TICKET
return FALSE;
}
void MDL_ticket::downgrade_lock(enum_mdl_type new_type)
{
/* Only allow downgrade from EXCLUSIVE and SHARED_NO_WRITE. */
DBUG_ASSERT(m_type == MDL_EXCLUSIVE ||
m_type == MDL_SHARED_NO_WRITE);
//此处打印出降级前的TICKET
if (m_hton_notified)
{
MySQL_mdl_set_status(m_psi, MDL_ticket::POST_RELEASE_NOTIFY);
m_ctx->get_owner()->notify_hton_post_release_exclusive(&m_lock->key);
m_hton_notified= false;
MySQL_mdl_set_status(m_psi, MDL_ticket::GRANTED);
}
//函数结尾答应出降级后的TICKET
}
bool
MDL_context::upgrade_shared_lock(MDL_ticket *mdl_ticket,
enum_mdl_type new_type,
ulong lock_wait_timeout)
{
MDL_REQUEST_INIT_BY_KEY(&mdl_new_lock_request,
&mdl_ticket->m_lock->key, new_type,
MDL_TRANSACTION);//构造一个request
//此处打印出来的TICKET类型
if (acquire_lock(&mdl_new_lock_request, lock_wait_timeout)) //尝试使用新的LOCK_TYPE进行加锁
DBUG_RETURN(TRUE);
is_new_ticket= ! has_lock(mdl_svp, mdl_new_lock_request.ticket);
lock= mdl_ticket->m_lock;
//下面进行一系列对MDL_LOCK的维护并且对所谓的合并操作
/* Code below assumes that we were upgrading to "obtrusive" type of lock. */
DBUG_ASSERT(lock->is_obtrusive_lock(new_type));
/* Merge the acquired and the original lock. @todo: move to a method. */
MySQL_prlock_wrlock(&lock->m_rwlock);
if (is_new_ticket)
{
m_tickets[MDL_TRANSACTION].remove(mdl_new_lock_request.ticket);
MDL_ticket::destroy(mdl_new_lock_request.ticket);
}
//此处打印出来的升级后TICKET类型
DBUG_RETURN(FALSE);
}
这个锁会在很多操作的时候都会出现，比如做任何一个DML/DDL操作都会触发，实际上DELTE/UPDATE/INSERT/FOR UPDATE等DML操作会在GLOBAL 上加IX锁，然后才会在本对象上加锁。而DDL 语句至少会在GLOBAL 上加IX锁，对象所属 SCHEMA上加IX锁，本对象加锁。
下面是 DELETE 触发的 GLOABL IX MDL LOCK：
2017-08-03T18:22:38.092205Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T18:22:38.092242Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T18:22:38.092276Z 3 [Note] (--->MDL PRINT) Namespace is:GLOBAL
2017-08-03T18:22:38.092310Z 3 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T18:22:38.092344Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_INTENTION_EXCLUSIVE(IX)
2017-08-03T18:22:38.092380Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_STATEMENT
2017-08-03T18:22:38.092551Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
我们注意一样它的持续周期为语句级别。
下面是 ALETER 语句触发的GLOABL IX MDL Lock：
2017-08-03T18:46:05.894871Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T18:46:05.894915Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T18:46:05.894948Z 3 [Note] (--->MDL PRINT) Namespace is:GLOBAL
2017-08-03T18:46:05.894980Z 3 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T18:46:05.895012Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_INTENTION_EXCLUSIVE(IX)
2017-08-03T18:46:05.895044Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_STATEMENT
2017-08-03T18:46:05.895076Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
所以这个MDL Lock无所不在，而只有是否兼容问题，如果不兼容则堵塞。scope lock的IX类型一般都是兼容的除非遇到S类型，下面讨论。
这把锁一般用在flush tables with read lock中，如下：
MySQL> flush tables with read lock;
Query OK, 0 rows affected (0.01 sec)
2017-08-03T18:19:11.603911Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T18:19:11.603947Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T18:19:11.603971Z 3 [Note] (--->MDL PRINT) Namespace is:GLOBAL
2017-08-03T18:19:11.603994Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED(S)
2017-08-03T18:19:11.604045Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_EXPLICIT
2017-08-03T18:19:11.604073Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T18:19:11.604133Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T18:19:11.604156Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T18:19:11.604194Z 3 [Note] (--->MDL PRINT) Namespace is:COMMIT
2017-08-03T18:19:11.604217Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED(S)
2017-08-03T18:19:11.604240Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_EXPLICIT
2017-08-03T18:19:11.604310Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
我们注意到其namspace为GLOBAL和COMMIT显然他们是scope lock ，他们的TYPE为S，那么很显然根据兼容性原则scope lock的MDL IX和MDL S 不兼容， flush tables with read lock 就会堵塞所有DELTE/UPDATE/INSERT/FOR UPDATE等DML和DDL操作，并且也会堵塞commit操作。
这个锁基本上大家也是经常用到只是没感觉到而已，比如我们一般desc操作，兼容矩阵如下：
操作记录如下：
MySQL> desc test.testsort10;
2017-08-03T19:06:05.843277Z 4 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T19:06:05.843324Z 4 [Note] (>MDL PRINT) Thread id is 4:
2017-08-03T19:06:05.843359Z 4 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:06:05.843392Z 4 [Note] (-->MDL PRINT) OBJ_name is:testsort10
2017-08-03T19:06:05.843425Z 4 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:06:05.843456Z 4 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T19:06:05.843506Z 4 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_HIGH_PRIO(SH)
2017-08-03T19:06:05.843538Z 4 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:06:05.843570Z 4 [Note] (------->MDL PRINT) Mdl status is:EMPTY
这中类型的优先级比较高，但是其和X不兼容。注意持续时间为MDL_TRANSACTION 。
这把锁一般用在非当前读取的select中，兼容性如下：
操作记录如下：
MySQL> select * from test.testsort10 limit 1;
2017-08-03T19:13:52.338764Z 4 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T19:13:52.338813Z 4 [Note] (>MDL PRINT) Thread id is 4:
2017-08-03T19:13:52.338847Z 4 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:13:52.338883Z 4 [Note] (-->MDL PRINT) OBJ_name is:testsort10
2017-08-03T19:13:52.338917Z 4 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:13:52.338950Z 4 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T19:13:52.339025Z 4 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_READ(SR)
2017-08-03T19:13:52.339062Z 4 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:13:52.339097Z 4 [Note] (------->MDL PRINT) Mdl status is:EMPTY
这里还是要提及一下平时我们偶尔会出现select也堵住的情况(比如DDL的某个阶段需要对象MDL X锁)。我们不得不抱怨MySQL居然会堵塞select其实这里也就是object mdl lock X 和SR 不兼容的问题(参考前面的兼容矩阵)。注意持续时间为MDL_TRANSACTION 。
这把锁一般用于DELTE/UPDATE/INSERT/FOR UPDATE等操作对table的加锁(当前读)，不包含DDL操作，但是要注意DML操作实际上还会有一个GLOBAL的IX的锁，前面已经提及过了，这把锁只是对象上的，兼容性如下：
操作记录如下：
MySQL> select * from test.testsort10 limit 1 for update;
2017-08-03T19:25:41.218428Z 4 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T19:25:41.218461Z 4 [Note] (>MDL PRINT) Thread id is 4:
2017-08-03T19:25:41.218493Z 4 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:25:41.218525Z 4 [Note] (-->MDL PRINT) OBJ_name is:testsort10
2017-08-03T19:25:41.218557Z 4 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:25:41.218588Z 4 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T19:25:41.218620Z 4 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_WRITE(SW)
2017-08-03T19:25:41.218677Z 4 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:25:41.218874Z 4 [Note] (------->MDL PRINT) Mdl status is:EMPTY
注意持续时间为MDL_TRANSACTION 。
这把锁很少用到源码注释只有如下：
Used by DML statements modifying tables and using the LOW_PRIORITY clause
不做解释了。
这把锁一般在ALTER TABLE语句中会用到，他可以升级为SNW,、SNRW、X，同时至少X锁也可以降级为SU实际上在Innodb ONLINE DDL中非常依赖它，由于它的存在那么DML(SW)和SELECT(SR)都不会堵塞，兼容性如下：
我们有必要研究一下他的兼容性，可以看到 OBJECT LOCK中(SELECT)SR和(DML)SW都是允许的，而在SCOPED LOCK中虽然DML DDL都会在GLOBAL 上锁，但是其类型都是IX。所以这个SU锁不堵塞DML/SELECT 读写操作进入Innodb引擎层，它是ONLINE DDL的基础。如果不兼容你都进入不了Innodb引擎层，更谈不上什么ONLINE DDL，注意我这里说的ALGORITHM=INPLACE的ONLINE DDL。
操作日志记录：
MySQL> alter table testsort12 add column it int not null;
Query OK, 0 rows affected (6.27 sec)
Records: 0 Duplicates: 0 Warnings: 0
2017-08-03T19:46:54.781453Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T19:46:54.781487Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T19:46:54.781948Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:46:54.781990Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T19:46:54.782026Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:46:54.782060Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_UPGRADABLE(SU)
2017-08-03T19:46:54.782096Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:46:54.782175Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T19:46:54.803898Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK will upgrade
2017-08-03T19:46:54.804201Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK upgrade TO
2017-08-03T19:46:54.804240Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T19:46:54.804254Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:46:54.804267Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T19:46:54.804280Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:46:54.804293Z 3 [Note] (----->MDL PRINT) Mdl type :MDL_EXCLUSIVE(X)
2017-08-03T19:46:54.804306Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:46:54.804319Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T19:46:54.855563Z 3 [Note] (downgrade_lock)THIS MDL LOCK will downgrade
2017-08-03T19:46:54.855693Z 3 [Note] (downgrade_lock) to this MDL lock
2017-08-03T19:46:54.855706Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T19:46:54.855717Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:46:54.856053Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T19:46:54.856069Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:46:54.856082Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_UPGRADABLE(SU)
2017-08-03T19:46:54.856094Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:46:54.856214Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T19:47:00.260166Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK will upgrade
2017-08-03T19:47:00.304057Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK upgrade TO
2017-08-03T19:47:00.304090Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T19:47:00.304105Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T19:47:00.304119Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T19:47:00.304132Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T19:47:00.304181Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_EXCLUSIVE(X)
2017-08-03T19:47:00.304196Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T19:47:00.304211Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T19:47:01.032329Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
我们需要简单分析一下，获得testsort12表上的MDL Lock大概流程如下：
2017-08-03T19:46:54.781487 获得 MDL_SHARED_UPGRADABLE(SU)
2017-08-03T19:46:54.804293 升级 MDL_EXCLUSIVE(X) 准备阶段
2017-08-03T19:46:54.855563 降级 MDL_SHARED_UPGRADABLE(SU) 执行阶段
2017-08-03T19:47:00.304057 升级 MDL_EXCLUSIVE(X) 提交阶段
不管如何这个ALTER操作还是比较费时的，从时间我们看到2017-08-03T19:46:54降级完成(SU)到2017-08-03T19:47:00这段时间，实际上是最耗时的实际上这里就是实际的Inplace重建，但是这个过程实际在MDL SU模式下所以不会堵塞DML/SELECT操作。这里再给大家提个醒，所谓的ONLINE DDL只是在Inplace重建阶段不堵塞DML/SELECT操作，还是尽量在数据库压力小的时候操作，如果有DML没有提交或者SELECT没有做完这个时候SW或者SR必然堵塞X，而X为高优先级能够堵塞所有操作。这样导致的现象就是由于DML未提交会堵塞DDL操作，而DDL操作会堵塞所有操作，基本对于这个TABLE的表全部操作堵塞（SW堵塞X，X堵塞所有操作）。
而对于ALGORITHM=COPY 在COPY阶段用的是SNW锁，接下来我就先来看看SNW锁。
SU可以升级为SNW而SNW可以升级为X，如前面所提及的用于ALGORITHM=COPY 中，保护数据的一致性。先看看它的兼容性如下：
从兼容矩阵可以看到，本锁不会堵塞SR，但是堵塞SW，当然也就堵塞了DML(SW)而SELECT(SR)不会堵塞，下面是部分操作记录日志：
MySQL> alter table testsort12 add column ik int not null, ALGORITHM=COPY ;
2017-08-03T20:07:58.413215Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK upgrade TO
2017-08-03T20:07:58.413241Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T20:07:58.413257Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T20:07:58.413273Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T20:07:58.413292Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T20:07:58.413308Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_NO_WRITE(SNW)
2017-08-03T20:07:58.413325Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T20:07:58.413341Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T20:08:25.392006Z 3 [Note] (upgrade_shared_lock)THIS MDL LOCK upgrade TO
2017-08-03T20:08:25.392024Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T20:08:25.392086Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T20:08:25.392159Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T20:08:25.392199Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T20:08:25.392214Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_EXCLUSIVE(X)
2017-08-03T20:08:25.392228Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T20:08:25.392242Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
我们可以发现如下：
2017-08-03T20:07:58.413308 获得了MDL_SHARED_NO_WRITE(SNW)
2017-08-03T20:08:25.392006 升级为MDL_EXCLUSIVE(X)
2017-08-03T20:07:58.413308到2017-08-03T20:08:25.392006就是实际COPY的时间，可见整个COPY期间只能SELECT，而不能DML。也是ALGORITHM=COPY和ALGORITHM=INPLACE的一个关键区别。
用于LOCK TABLES READ 语句，兼容性如下：
根据兼容性可以发现，堵塞DML(SW)但是SELECT(SR)还是可以的。下面是操作日志：
MySQL> lock table testsort12 read;
Query OK, 0 rows affected (0.01 sec)
2017-08-03T21:08:27.267947Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T21:08:27.267979Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T21:08:27.268009Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T21:08:27.268040Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T21:08:27.268070Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T21:08:27.268113Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_READ_ONLY(SRO)
2017-08-03T21:08:27.268145Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T21:08:27.268175Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
用于LOCK TABLES WRITE语句，兼容性如下：
可以看到DML(SW)和SELECT(SR)都被它堵塞，但是还可以DESC(SH)。
操作日志记录如下：
MySQL> lock table testsort12 write;
Query OK, 0 rows affected (0.00 sec)
2017-08-03T21:13:07.113347Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T21:13:07.113407Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T21:13:07.113435Z 3 [Note] (--->MDL PRINT) Namespace is:GLOBAL
2017-08-03T21:13:07.113458Z 3 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T21:13:07.113482Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_INTENTION_EXCLUSIVE(IX)
2017-08-03T21:13:07.113505Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_STATEMENT
2017-08-03T21:13:07.113604Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T21:13:07.113637Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T21:13:07.113660Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T21:13:07.113681Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T21:13:07.113703Z 3 [Note] (-->MDL PRINT) OBJ_name is:
2017-08-03T21:13:07.113725Z 3 [Note] (--->MDL PRINT) Namespace is:SCHEMA
2017-08-03T21:13:07.113746Z 3 [Note] (---->MDL PRINT) Fast path is:(Y)
2017-08-03T21:13:07.113768Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_INTENTION_EXCLUSIVE(IX)
2017-08-03T21:13:07.113791Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T21:13:07.113813Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
2017-08-03T21:13:07.113842Z 3 [Note] (acquire_lock)THIS MDL LOCK acquire ok!
2017-08-03T21:13:07.113865Z 3 [Note] (>MDL PRINT) Thread id is 3:
2017-08-03T21:13:07.113887Z 3 [Note] (->MDL PRINT) DB_name is:test
2017-08-03T21:13:07.113922Z 3 [Note] (-->MDL PRINT) OBJ_name is:testsort12
2017-08-03T21:13:07.113945Z 3 [Note] (--->MDL PRINT) Namespace is:TABLE
2017-08-03T21:13:07.113975Z 3 [Note] (----->MDL PRINT) Mdl type is:MDL_SHARED_NO_READ_WRITE(SNRW)
2017-08-03T21:13:07.113998Z 3 [Note] (------>MDL PRINT) Mdl duration is:MDL_TRANSACTION
2017-08-03T21:13:07.114021Z 3 [Note] (------->MDL PRINT) Mdl status is:EMPTY
除此之外可以发现语句还需要GLOBAL和SCHEMA上的IX锁，换句话说flush tables with read lock; 会堵塞‘lock table testsort12 write’，但是‘lock table testsort12 read’却不会堵塞。
用于各种DDL操作，实际上基本全部的DDL都会涉及到这个锁，即便是ONLINE DDL也会在准备和提交阶段获取本锁，因此ONLINE DDL不是完全不堵塞的，只是堵塞时间很短很短，兼容性如下：
我们在验证SU和SNW MDL Lock类型的时候已经看到了操作记录，不做补充了。
作者微信：gp_22389860
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
