MySQL 中定位 DDL 被阻塞的问题及解决方案

更新时间：2022年01月11日 14:17:45 作者：iVictor

DDL 被阻塞了，如何找到阻塞它的 SQL?下面，就这个问题，给一个清晰明了、拿来即用的解决方案，本文通过一个简单的demo给大家介绍的非常详细，感兴趣的朋友跟随小编一起看看吧

DDL 被阻塞了，如何找到阻塞它的 SQL?

经常碰到开发、测试童鞋会问，线下开发、测试环境，执行了一个DDL，发现很久都没有执行完，是不是被阻塞了？要怎么解决？

包括在群里，也经常会碰到类似问题：DDL 被阻塞了，如何找到阻塞它的 SQL ？

实际上，如何解决 DDL 被阻塞的问题，是 MySQL 中一个共性且高频的问题。

下面，就这个问题，给一个清晰明了、拿来即用的解决方案：

怎么判断一个DDL是不是被阻塞了？当DDL被阻塞时，怎么找出阻塞它的会话？

怎么判断一个 DDL是不是被阻塞了?

首先，看一个简单的Demo

session1> create table sbtest.t1(id int primary key,name varchar(10));
Query OK, 0 rows affected (0.02 sec)
session1> insert into sbtest.t1 values(1,'a');
Query OK, 1 row affected (0.01 sec)
session1> begin;
Query OK, 0 rows affected (0.00 sec)
session1> select * from sbtest.t1;
+----+------+
| id | name |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)
session2> alter table sbtest.t1 add c1 datetime;
阻塞中。。。
session3> show processlist;
+----+-----------------+-----------+------+---------+-------+---------------------------------+---------------------------------------+
| Id | User            | Host      | db   | Command | Time  | State                           | Info                                  |
+----+-----------------+-----------+------+---------+-------+---------------------------------+---------------------------------------+
|  5 | event_scheduler | localhost | NULL | Daemon  | 47628 | Waiting on empty queue          | NULL                                  |
| 24 | root            | localhost | NULL | Sleep   |    11 |                                 | NULL                                  |
| 25 | root            | localhost | NULL | Query   |     5 | Waiting for table metadata lock | alter table sbtest.t1 add c1 datetime |
| 26 | root            | localhost | NULL | Query   |     0 | init                            | show processlist                      |
+----+-----------------+-----------+------+---------+-------+---------------------------------+---------------------------------------+
4 rows in set (0.00 sec)

判断一个 DDL 是不是被阻塞了，很简单，就是执行 show processlist ，查看 DDL 操作对应的状态。

如果显示的是 Waiting for table metadata lock ，则意味着这个 DDL 被阻塞了。

DDL 一旦被阻塞了，后续针对该表的所有操作都会被阻塞，都会显示 Waiting for table metadata lock 。这也是 DDL 让人闻之色变的原因。

碰到了类似场景，要么 Kill DDL 操作，要么 Kill 阻塞 DDL 的会话。

Kill DDL 操作是一个治标不治本的方法，毕竟 DDL 操作总要执行。

除此之外，对于 DDL 操作，需要获取元数据库锁的阶段有两个：DDL 开始之初和 DDL 结束之前。如果是后者，就意味着之前的操作都要回滚，成本相对较高。

所以，碰到类似场景，我们一般都会 Kill 阻塞 DDL 的会话。

那么，怎么知道是哪些会话阻塞了 DDL 呢？

下面我们看看具体的定位方法。

定位方法

方法一：sys.schema_table_lock_waits

sys.schema_table_lock_waits 是MySQL 5.7引入的，用来定位 DDL 被阻塞的问题。

针对上面这个Demo。

我们看看sys.schema_table_lock_waits的输出。

mysql> select * from sys.schema_table_lock_waits\G
*************************** 1. row ***************************
               object_schema: sbtest
                 object_name: t1
           waiting_thread_id: 62
                 waiting_pid: 25
             waiting_account: root@localhost
           waiting_lock_type: EXCLUSIVE
       waiting_lock_duration: TRANSACTION
               waiting_query: alter table sbtest.t1 add c1 datetime
          waiting_query_secs: 17
 waiting_query_rows_affected: 0
 waiting_query_rows_examined: 0
          blocking_thread_id: 61
                blocking_pid: 24
            blocking_account: root@localhost
          blocking_lock_type: SHARED_READ
      blocking_lock_duration: TRANSACTION
     sql_kill_blocking_query: KILL QUERY 24
sql_kill_blocking_connection: KILL 24
*************************** 2. row ***************************
               object_schema: sbtest
                 object_name: t1
           waiting_thread_id: 62
                 waiting_pid: 25
             waiting_account: root@localhost
           waiting_lock_type: EXCLUSIVE
       waiting_lock_duration: TRANSACTION
               waiting_query: alter table sbtest.t1 add c1 datetime
          waiting_query_secs: 17
 waiting_query_rows_affected: 0
 waiting_query_rows_examined: 0
          blocking_thread_id: 62
                blocking_pid: 25
            blocking_account: root@localhost
          blocking_lock_type: SHARED_UPGRADABLE
      blocking_lock_duration: TRANSACTION
     sql_kill_blocking_query: KILL QUERY 25
sql_kill_blocking_connection: KILL 25
2 rows in set (0.00 sec)

只有一个 alter 操作，却产生了两条记录，而且两条记录的 Kill 对象还不一样，其中一条 Kill 的对象还是 alter 操作本身。

如果对表结构不熟悉或不仔细看记录内容的话，难免会 Kill 错对象。

不仅如此，在 DDL 操作被阻塞后，如果后续有 N 个查询被 DDL 操作堵塞，还会产生 N*2 条记录。

在定位问题时，这 N*2 条记录完全是个噪音。

这个时候，就需要我们对上述记录进行过滤了。

过滤的关键是 blocking_lock_type 不等于 SHARED_UPGRADABLE。

SHARED_UPGRADABLE 是一个可升级的共享元数据锁，加锁期间，允许并发查询和更新，常用在 DDL 操作的第一阶段。

所以，阻塞DDL的不会是SHARED_UPGRADABLE。

故而，针对上面这个 case，我们可以通过下面这个查询来精确地定位出需要 Kill 的会话。

SELECT sql_kill_blocking_connection
FROM sys.schema_table_lock_waits
WHERE blocking_lock_type <> 'SHARED_UPGRADABLE'
 AND waiting_query = 'alter table sbtest.t1 add c1 datetime';

方法二：Kill DDL 之前的会话

sys.schema_table_lock_waits 是 MySQL 5.7 才引入的。

但在实际生产环境，MySQL 5.6还是占有相当多的份额。

如何解决MySQL 5.6的这个痛点呢？

细究下来，导致 DDL 被阻塞的操作，无非两类：

表上有慢查询未结束。

表上有事务未提交。

其中，第一类比较好定位，通过 show processlist 就能发现。

而第二类仅凭 show processlist 很难定位，因为未提交事务的连接在 show processlist 中的状态同空闲连接一样，都是 Sleep 。

所以，网上有 Kill 空闲连接的说法，其实也不无道理，但这样做就太简单粗暴了，难免会误杀。

其实，既然是事务，在 information_schema.innodb_trx中肯定会有记录，如 session1 中的事务，在表中的记录如下，

mysql> select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 421568246406360
                 trx_state: RUNNING
               trx_started: 2022-01-02 08:53:50
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 0
       trx_mysql_thread_id: 24
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 0
     trx_lock_memory_bytes: 1128
           trx_rows_locked: 0
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL
1 row in set (0.00 sec)

其中 trx_mysql_thread_id 是线程 id ，结合 information_schema.processlist ，可进一步缩小范围。

所以，我们可以通过下面这个 SQL ，定位出执行时间早于 DDL 的事务。

SELECT concat('kill ', i.trx_mysql_thread_id, ';')
FROM information_schema.innodb_trx i, (
    SELECT MAX(time) AS max_time
    FROM information_schema.processlist
    WHERE state = 'Waiting for table metadata lock'
      AND (info LIKE 'alter%'
      OR info LIKE 'create%'
      OR info LIKE 'drop%'
      OR info LIKE 'truncate%'
      OR info LIKE 'rename%'
  )) p
WHERE timestampdiff(second, i.trx_started, now()) > p.max_time;

可喜的是，当前正在执行的查询也会显示在information_schema.innodb_trx中。

所以，上面这个 SQL 同样也适用于慢查询未结束的场景。

MySQL 5.7中使用sys.schema_table_lock_waits的注意事项

sys.schema_table_lock_waits 视图依赖了一张 MDL 相关的表-performance_schema.metadata_locks。

该表是 MySQL 5.7 引入的，会显示 MDL 的相关信息，包括作用对象、锁的类型及锁的状态等。

但在 MySQL 5.7 中，该表默认为空，因为与之相关的 instrument 默认没有开启。MySQL 8.0 才默认开启。

mysql> select * from performance_schema.setup_instruments where name='wait/lock/metadata/sql/mdl';
+----------------------------+---------+-------+
| NAME                       | ENABLED | TIMED |
+----------------------------+---------+-------+
| wait/lock/metadata/sql/mdl | NO      | NO    |
+----------------------------+---------+-------+
1 row in set (0.00 sec)

所以，在 MySQL 5.7 中，如果我们要使用 sys.schema_table_lock_waits ，必须首先开启 MDL 相关的 instrument。

开启方式很简单，直接修改 performance_schema.setup_instruments 表即可。

具体SQL如下。

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'wait/lock/metadata/sql/mdl';

但这种方式是临时生效，实例重启后，又会恢复为默认值。

建议同步修改配置文件。

[mysqld]
performance-schema-instrument='wait/lock/metadata/sql/mdl=ON'

总结

1. 执行 show processlist ，如果 DDL 的状态是 Waiting for table metadata lock ，则意味着这个 DDL 被阻塞了。

2. 定位导致 DDL 被阻塞的会话，常用的方法有两种：

2.1 sys.schema_table_lock_waits

SELECT sql_kill_blocking_connection
FROM sys.schema_table_lock_waits
WHERE blocking_lock_type <> 'SHARED_UPGRADABLE'
  AND (waiting_query LIKE 'alter%'
  OR waiting_query LIKE 'create%'
  OR waiting_query LIKE 'drop%'
  OR waiting_query LIKE 'truncate%'
  OR waiting_query LIKE 'rename%');

这种方法适用于 MySQL 5.7 和 8.0。

注意，MySQL 5.7 中，MDL 相关的 instrument 默认没有打开。

2.2 Kill DDL 之前的会话

SELECT concat('kill ', i.trx_mysql_thread_id, ';')
FROM information_schema.innodb_trx i, (
    SELECT MAX(time) AS max_time
    FROM information_schema.processlist
    WHERE state = 'Waiting for table metadata lock'
      AND (info LIKE 'alter%'
      OR info LIKE 'create%'
      OR info LIKE 'drop%'
      OR info LIKE 'truncate%'
      OR info LIKE 'rename%'
  )) p
WHERE timestampdiff(second, i.trx_started, now()) > p.max_time;

如果 MySQL 5.7 中 MDL 相关的 instrument 没有打开或在 MySQL 5.6 中，可使用该方法。

到此这篇关于MySQL 中如何定位 DDL 被阻塞的问题的文章就介绍到这了,更多相关MySQL定位 DDL 被阻塞内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

sql 流水号获取代码实例
这篇文章主要介绍了sql 流水号获取代码实例,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
2019-09-09
新手学习MySQL索引
如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话，那么没有索引的MySQL就是一个人力三轮车。通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢，下面小编来带大家了解下索引
2019-05-05
MySql nion与Limit查询介绍
这篇文章主要为大家详细介绍一下MySQL数据库中union、limit查询的使用，文中的示例代码讲解详细，对我们学习MySQL有一定帮助，需要的可以参考一下
2022-09-09
MySQL详细讲解变量variables的用法
MySQL系统变量(system variables)实际上是一些系统参数，用于初始化或设定数据库对系统资源的占用，文件存放位置等等，本篇文章我们来探究一下variables
2022-06-06
MySQL中distinct与group by语句的一些比较及用法讲解
这篇文章主要介绍了MySQL中distinct与group by的一些比较及用法讲解,二者在查询操作中的用法有很多相似之处,需要的朋友可以参考下
2016-01-01
深入探究MySQL中使用where 1=1是否存在性能影响
最近在项目中使用 mybatis 写 SQL 使用了 where 1=1 来简化多条件拼接的写法,案例如下,借此聊聊多条件拼接的常见的一些写法以及 where 1=1 是否存在性能影响,需要的朋友可以参考下
2024-02-02
MySQL递归查询的几种实现方法
本文主要介绍了MySQL递归查询的几种实现方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
2024-10-10
MySQL中limit对查询语句性能的影响
我们知道，当limit offset rows中的offset很大时，会出现效率问题，那么如果提高limit的执行效率呢
2021-09-09
MySQL数据库优化技术之配置技巧总结
这篇文章主要介绍了MySQL数据库优化技术之配置技巧,较为详细的总结分析了MySQL进行硬件级软件优化的相关方法与注意事项,需要的朋友可以参考下
2016-07-07
在windows上安装不同(两个)版本的Mysql数据库的教程详解
这篇文章主要介绍了在windows上安装不同(两个)版本的Mysql数据库 ,需要的朋友可以参考下
2019-04-04