我的mysql服务器出现意外状态。我有一个执行查询的连接，它在“等待表元数据锁”中停留了很长一段时间（超过1643秒）。这个查询是我系统中一个非常繁忙的表上的一个drop索引。
实际上我已经试过很多次了。首先，数据库很忙，其他连接正在执行多个操作（都是读写操作）。我想这可能是原因，所以我按顺序试了一下：
终止在同一个表和同一个“等待表元数据锁”上运行查询的任何进程
使用sleep命令甚至杀死进程
从远程主机上删除每个进程和任何授权（在只有根用户可以连接并且没有其他用户连接之后，应用程序本身就与数据库断开连接）
取消并重新运行命令（这将是唯一激活的命令）
即使在那种状态下，问题也会持续几分钟。唯一活动的进程查询是：
ID: 2398884
USER: root
HOST: localhost
DB: zoom
COMMAND: Query
TIME: 1643
STATE: Waiting for table metadata lock
INFO: DROP INDEX index_x ON tb.schema后来我们决定重新启动mysqld。服务器恢复后问题就消失了。我可以运行drop index命令。
我还没发现有人有类似的情况。在某些情况下这正常吗？我试图找出哪个事务导致了“等待表元数据锁”。但没能认出任何人。
注意：除了drop索引和我自己的根连接来检查进度和状态之外，还有binlog dump复制查询正在运行
1条答案
按热度按时间vc6uscn91#
不，这是不正常的，我相信你只是没有杀死正确的线程。不需要重新启动mysql。如果是的话，我和我工作的公司会第一个放弃它。
当一个事务接触到一个表，而另一个事务（您的drop index语句）想要有一个锁，但第一个事务还没有提交时，就会发生元数据锁。听起来太普通了，但要坚持到底：
我说的“触摸”就是这个意思。一个简单的选择就足够了，它可以发生在事务中的任何地方。如果之后不再运行语句，或者运行另一个语句（只要不是
commit;或者rollback;)，此事务阻止其他事务获取元数据的锁。现在session2正在等待元数据锁。
关于你的尝试：
必须终止的不一定是当前正在同一表上运行语句的事务。杀死其他也在等待元数据锁的语句并没有帮助，它们也只是受害者。但也不疼。
不错的主意。
不知道你是什么意思。但取消补助金肯定没有帮助。新的授权或删除的授权不适用于仍在运行的事务。必须重新打开会话才能使更改的授权生效。
这根本没用。
话虽如此，我确实不明白为什么你的相关问题中被接受的答案有100多张赞成票。这些查询实际上根本没有显示锁。不过，第二个答案是对的。首先终止运行时间最长的事务。
不过请注意，您必须检查
ACTIVE x seconds输出中的部件SHOW ENGINE INNODB STATUS\G在TRANSACTIONS部分。不要使用time进程列表中的值。这只指示自上次更改此线程的状态以来的时间。请在此处阅读有关元数据锁的详细信息
哦，如果您使用的是MySQL5.7或更新版本，请务必阅读本文。