MySQL从5.5版别初步，新增元数据锁，也就是metadata lock，简称MDL锁。
MDL锁的主要目是保护表元数据并行央求进程中不被批改，例如会话1在实行SELECT查询数据，会话2要新增一列，这时第二个会话会被阻塞，防止构成会话1前后看到的表结构不一致。
当然了，MDL后来被扩展了，并不只是针对表（TABLE）方针，也包含库（SCHEMA）、表空间（TABLESPACE）、存储程序（进程、函数、触发器、定时器）等方针，也遭到MDL的保护。此外，MDL锁也会阻塞全局 COMMIT 行为，比如加了FTWRL（FLUSH TABLE WITH READ LOCK）后，就会持有一个全局的 COMMIT 同享锁，此时会阻遏其他会话的事务提交。
我们从 performance_schema.metadata_lock 就可以看到MDL的详细情况，从MySQL 5.7版别初步，还可以从 sys.schema_table_lock_waits 查看MDL阻塞等候的情况。要特别注意的是，MDL锁等候超时阈值由选项 lock_wait_timeout 控制，该选项默认值是 31536000秒，也就是 一年、一年、一年（重要的话重复三遍），建议调低，比如改成5-10分钟，建议最长不逾越1小时（想想，这种MDL等候逾越1小时还不报警的话，DBA也该下岗了吧）。A8站源码交易平台
其他，想要在PFS（performance_schema）和 sys schema中能看到MDL概略的话，需求先启用相关的设置：（横屏观看）
[root@yejr.me]> use performance_schema;[root@yejr.me]> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';[root@yejr.me]> UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME =‘wait/lock/metadata/sql/mdl';
然后就能查看其时是否有MDL锁了：（横屏观看）
# session1实行一个未结束的只读事务[root@yejr.me]> begin; select * from test.t1 limit 1;# session2 查看MDL概略[root@yejr.me]> SELECT * FROM metadata_locksG*************************** 1. row *************************** OBJECT_TYPE: TABLE OBJECT_SCHEMA: test OBJECT_NAME: t1 COLUMN_NAME: NULLOBJECT_INSTANCE_BEGIN: 140334142005184 LOCK_TYPE: SHARED_READ -- 该MDL央求类型为同享读 LOCK_DURATION: TRANSACTION -- 该MDL央求处于事务等级 LOCK_STATUS: GRANTED -- 该MDL央求已获得 SOURCE: sql_parse.cc:5929 OWNER_THREAD_ID: 1892 -- 线程ID OWNER_EVENT_ID: 13
已有各路大神对MDL做了详细解析，所以本文不再赘述，我更喜欢写点接地气的。所以我们一同分析一个非常经典的MDL等候案例，借此分析遇到这种问题时，该怎样分析和判别，以及怎样应对处理。（横屏观看）
————————————————
这时实行 SHOW PROCESSLIST 的话，能看到下面这样的现场（删去了部分无用输出列）（横屏观看）
+------+------+---------------------------------+--------------------------+| Id | Time | State | Info |+------+------+---------------------------------+--------------------------+| 1853 | 0 | starting | show processlist || 1854 | 134 | Waiting for table metadata lock | alter table t1 add cx int|| 1855 | 83 | Waiting for table metadata lock | select * from t1 limit 1 |+------+------+---------------------------------+--------------------------+
假设只看现场，我们是没方法分分出终究哪个线程导致的MDL阻塞，这正是MySQL 5.7之前版其他痛苦之处，遇到MDL等候，只能靠DBA的阅历、感觉去分析，还不必定彻底可靠。
但是，5.7版别之后，我们就可以用PFS和sys schema进行跟踪分析了：（横屏观看）
# 1、查看其时的MDL央求情况（删去部分信息）[root@yejr.me]> select * from performance_schema.metadata_locks;+-------------+-----------+---------------------+---------------+-------------+------+| OBJECT_TYPE | OBJECT_NAM| LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | TID |+-------------+-----------+---------------------+---------------+-------------+------+| TABLE | t1 | SHARED_READ | TRANSACTION | GRANTED | 1892 || GLOBAL | NULL | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | 1893 || SCHEMA | NULL | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | 1893 || TABLE | t1 | SHARED_UPGRADABLE | TRANSACTION | GRANTED | 1893 || BACKUP LOCK | NULL | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | 1893 || TABLESPACE | test/t1 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | 1893 || TABLE | #sql-e953_| EXCLUSIVE | STATEMENT | GRANTED | 1893 || TABLE | t1 | EXCLUSIVE | TRANSACTION | PENDING | 1893 || TABLE | t1 | SHARED_READ | TRANSACTION | PENDING | 1894 |+-------------+-----------+---------------------+---------------+-------------+------+# 2、查看其时的MDL等候情况[root@yejr.me]> select * from sys.schema_table_lock_waitsG*************************** 1. row *************************** object_schema: test object_name: t1 waiting_thread_id: 1893 -- 等候的线程ID waiting_pid: 1854 -- 等候的联接PID waiting_account: root@localhost waiting_lock_type: EXCLUSIVE -- 等候的锁类型 waiting_lock_duration: TRANSACTION waiting_query: alter table t1 drop cx waiting_query_secs: 134 -- 锁等候时长 waiting_query_rows_affected: 0 waiting_query_rows_examined: 0 blocking_thread_id: 1892 -- 这儿的线程ID值对应上面的TID blocking_pid: 1853 -- 联接PID，对应下方的trx_mysql_thread_id blocking_account: root@localhost blocking_lock_type: SHARED_READ -- 阻塞的锁类型 blocking_lock_duration: TRANSACTION sql_kill_blocking_query: KILL QUERY 1853sql_kill_blocking_connection: KILL 1853*************************** 2. row *************************** object_schema: test object_name: t1 waiting_thread_id: 1894 waiting_pid: 1855 waiting_account: root@localhost waiting_lock_type: SHARED_READ waiting_lock_duration: TRANSACTION waiting_query: select * from t1 limit 1 waiting_query_secs: 83 waiting_query_rows_affected: 0 waiting_query_rows_examined: 0 blocking_thread_id: 1892 blocking_pid: 1853 blocking_account: root@localhost blocking_lock_type: SHARED_READ blocking_lock_duration: TRANSACTION sql_kill_blocking_query: KILL QUERY 1853sql_kill_blocking_connection: KILL 1853*************************** 3. row *************************** object_schema: test object_name: t1 waiting_thread_id: 1893 waiting_pid: 1854 waiting_account: root@localhost waiting_lock_type: EXCLUSIVE waiting_lock_duration: TRANSACTION waiting_query: alter table t1 drop cx waiting_query_secs: 83 waiting_query_rows_affected: 0 waiting_query_rows_examined: 0 blocking_thread_id: 1893 blocking_pid: 1854 blocking_account: root@localhost blocking_lock_type: SHARED_UPGRADABLE blocking_lock_duration: TRANSACTION sql_kill_blocking_query: KILL QUERY 1854sql_kill_blocking_connection: KILL 1854*************************** 4. row *************************** object_schema: test object_name: t1 waiting_thread_id: 1894 waiting_pid: 1855 waiting_account: root@localhost waiting_lock_type: SHARED_READ waiting_lock_duration: TRANSACTION waiting_query: select * from t1 limit 1 waiting_query_secs: 83 waiting_query_rows_affected: 0 waiting_query_rows_examined: 0 blocking_thread_id: 1893 blocking_pid: 1854 blocking_account: root@localhost blocking_lock_type: SHARED_UPGRADABLE blocking_lock_duration: TRANSACTION sql_kill_blocking_query: KILL QUERY 1854sql_kill_blocking_connection: KILL 1854# 3、趁便查看其时是否有生动未提交的事务，一般持续时间最久的事务也是引起大面积MDL锁阻塞的根源[root@yejr.me]> select trx_id,trx_state,time_to_sec(timediff(now(), trx_started)) as trx_active_secs, trx_mysql_thread_id as pid, trx_query from information_schema.innodb_trx order by trx_active_secs desc G*************************** 1. row *************************** trx_id: 281479749621520 trx_state: RUNNINGtrx_active_secs: 226 pid: 1853 trx_query: select trx_id,trx_state...
上述检验的环境是：
[root@yejr.me]>...Server version: 8.0.16 MySQL Community Server - GPL...
问题分析
从上面的效果可分析得到以下结论：
联接PID=1854的那个会话，被联接PID=1853的会话阻塞了
联接PID=1855的那个会话，被联接PID=1854的会话阻塞了
联接PID=1855被阻塞的源头也可以追溯到PID=1853那个会话
也就是：session1阻塞session2，然后 session2阻塞session3
问题解决方法：
想要让session2和3都不被阻塞，只需求让session1上持有的锁开释即可
虽然上面提示可以实行KILL QUERY 1853，但实际上是不管用的，因为PID=1853中导致MDL等候的SQL现已实行结束，只是事务还没提交算了，因此正确的方法是实行 KILL 1853 彻底杀掉该联接，回滚相应的事务，开释MDL锁
终究多说一下，MDL是在MySQL server层的锁，而InnoDB层也有表等级上的IS/IX锁，二者并不是一回事。enjoy MySQL :)
A8站源码交易平台
