MySQL出现Waiting for table metadata lock的场景浅析

共计 1609 个字符，预计需要花费 5 分钟才能阅读完成。

MySQL 版本为 5.6.12。

在进行 alter table 操作时，有时会出现 Waiting for table metadata lock 的等待场景。而且，一旦 alter table TableA 的操作停滞在 Waiting for table metadata lock 的状态，后续对 TableA 的任何操作（包括读）都无法进行，也会在 Opening tables 的阶段进入 Waiting for table metadata lock 的队列。如果是产品环境的核心表出现了这样的锁等待队列，就会造成灾难性的后果。

造成 alter table 产生 Waiting for table metadata lock 的原因其实很简单，一般是以下几个简单的场景：

场景一：

通过 show processlist 可以看到 TableA 上有正在进行的操作（包括读），此时 alter table 语句无法获取到 metadata 独占锁，会进行等待。

这是最基本的一种情形，这个和 mysql 5.6 中的 online ddl 并不冲突。一般 alter table 的操作过程中（见下图），在 after create 步骤会获取 metadata 独占锁，当进行到 altering table 的过程时（通常是最花时间的步骤），对该表的读写都可以正常进行，这就是 online ddl 的表现，并不会像之前在整个 alter table 过程中阻塞写入。（当然，也并不是所有类型的 alter 操作都能 online 的，具体可以参见官方手册：http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html）

场景二：

通过 show processlist 看不到 TableA 上有任何操作，但实际上存在有未提交的事务，可以在 information_schema.innodb_trx 中查看到。在事务没有完成之前，TableA 上的锁不会释放，alter table 同样获取不到 metadata 的独占锁。

场景三：

通过 show processlist 看不到 TableA 上有任何操作，在 information_schema.innodb_trx 中也没有任何进行中的事务。这很可能是因为在一个显式的事务中， 对 TableA 进行了一个失败的操作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效。从 performance_schema.events_statements_current 表中可以查到失败的语句。

官方手册上对此的说明如下：

If the server acquires metadata locks for a statement that is syntactically valid but fails during execution, it does not release the locks early. Lock release is still deferred to the end of the transaction because the failed statement is written to the binary log and the locks protect log consistency.

也就是说除了语法错误，其他错误语句获取到的锁在这个事务提交或回滚之前，仍然不会释放掉。because the failed statement is written to the binary log and the locks protect log consistency 但是解释这一行为的原因很难理解，因为错误的语句根本不会被记录到二进制日志。

总之，alter table 的语句是很危险的，在操作之前最好确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句。如果有 alter table 的维护任务，在无人监管的时候运行，最好通过 lock_wait_timeout 设置好超时时间，避免长时间的 metedata 锁等待。

：