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';