问题
最近维护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高可用平台)，把读操作自动负载均衡到从库。
