MySQL运维-元数据锁问题定位

问题

最近维护MySQL数据库时，有个业务报障说所有的SQL语句都超时，执行了5分钟都执行不完。
我登录到他的MySQL后，执行了Show Process就发现问题了。
过程是他在一个表上执行了一个大查询，查询没有结束的情况下，又在该表发起了一个DDL语句，然后后续在该表上的SQL语句执行就一直在等待了。
具体的细节先不分析，让我们来重现这个场景，并在场景中进行分析。

环境准备

首先我们准备一张表，并在表中插入一点数据。

mysql> CREATE TABLE `t` (
    ->   `id` int(11) NOT NULL,
    ->   `name` varchar(30) DEFAULT NULL,  
    ->   PRIMARY KEY (`id`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 
Query OK, 0 rows affected (0.05 sec)

mysql> insert into t values ( 1, '123') ;
Query OK, 1 row affected (0.03 sec)

问题重现

为了重现问题，我们至少需要4个会话，因为所有的SQL语句执行都会堵住，我们按照会话执行的先后顺序来执行。

• 会话1
  在会话1中执行一条大查询，这条查询语句要执行很长时间。

mysql> select id , name , sleep(300) from t ; 

• 会话2
  发起一条DDL操作。

mysql> alter table t add ts timestamp;

因为DDL语句会申请MDL锁，MDL锁是表级别独占锁，前面有一条查询t表的SQL语句没有结束，所以该DDL语句会等待。

• 会话3
  发起t表上的其他任何语句，都会堵住，这里执行一条简单sql语句。

mysql> select * from t where id=1 ;

可以看到会话堵住了。

• 会话4
  在该会话，我们来通过show processlist 看看发生了什么？

mysql> show processlist ; 
+--------+-------------+--------------------+------------+-------------+-------+-----------------------------------------------------------------------------+---------------------------------------+
| Id     | User        | Host               | db         | Command     | Time  | State                                                                       | Info                                  |
+--------+-------------+--------------------+------------+-------------+-------+-----------------------------------------------------------------------------+---------------------------------------+
| 177915 | test         | 127.0.0.1:27538  | testdb     | Query       |    17 | User sleep                                                                  | select id , name , sleep(300) from t  |
| 178701 | test         | 127.0.0.1:28316  | testdb     | Query       |    15 | Waiting for table metadata lock                                             | alter table t add column ts timestamp |
| 178751 | test         | 127.0.0.1:28346  | testdb     | Query       |    12 | Waiting for table metadata lock                                             | select * from t where id=1            |
| 188250 | test         | 127.0.0.1:37604  | testdb     | Query       |     0 | init                                                                        | show processlist                      |
+--------+-------------+--------------------+------------+-------------+-------+-----------------------------------------------------------------------------+---------------------------------------+

从show process结果中可以看到，第一条sql语句select id , name , sleep(300) from t 正在执行中，而第二条和第三条sql语句都在等待MDL锁。
在这个案例中第一条大SQL是起因，结合DDL操作就会出现该问题。

如何避免文中的问题

如果我们按照上面问题重现的步骤在一个MySQL上执行那么基本上没法避免出现MDL锁的问题。
业务方问咨询的时候，我建议他尽量不要自己执行DDL，在数据库管理平台申请SQL，我们的平台会审核后，对于DDL语句，会在底层通过pt工具执行，依赖防止大表ALTER操作影响后续的SQL，而来，pt工具在执行DDL之前会判断处理该表上的长SQL，如果超过10s，会直接kill掉sql语句后，再执行DDL。这样就避免了MDL锁的出现。
当然最好的方式是大查询SQL不要在主库执行，在从库中执行影响就会很小了，而且可以通过代理层(参考一步一步打造MySQL高可用平台)，把读操作自动负载均衡到从库。