本文共 1784 字，大约阅读时间需要 5 分钟。

MySQL数据库查询长时间挂起与操作超时问题解决方案

近期项目中，数据库查询频繁出现挂起现象，应用程序启动后也经常报操作超时。测试人员反馈数据库连接失败，所有查询都无法完成，通过使用show processlist工具查看进程状态，发现屏幕上密密麻麻地充斥着Waiting for table metadata lock状态的连接。这让我立刻联想到可能存在大量未处理的事务，导致数据库锁机制陷入僵局。

问题分析

经过初步排查，发现该问题的根源与MySQL的DDL操作相关。具体来说，当数据库执行alter table等DDL操作时，如果涉及的表中存在未提交的事务（UNCOMMITTED TRANSACTIONS），就会导致Waiting for table metadata lock状态出现。一旦进入此状态，后续对该表的所有操作都会被阻塞，这严重影响了数据库的正常运行。

解决方案

为了迅速解决此问题，我采取以下步骤进行排查和修复：

1. 检查未提交的事务

首先，需要确认数据库中是否存在未提交的事务。可以通过检查information_schema.innodb_trx表来获取相关信息。执行以下SQL语句：

SELECT trx_state, trx_started, trx_mysql_thread_id, trx_queryFROM information_schema.innodb_trx\G

• trx_state：表示事务的状态，通常为RUNNING。
• trx_started：记录事务的启动时间，若时间过长，需分析该事务是否合理。
• trx_mysql_thread_id：MySQL线程ID，可以用于杀死进程。
• trx_query：事务中执行的具体SQL语句。

通过查看这些信息，可以快速定位到可能导致问题的具体事务进程。

2. 调整锁超时阈值

默认情况下，lock_wait_timeout的值为一年（31536000秒），这会导致在出现Waiting for table metadata lock状态时，数据库等待时间过长，难以及时发现问题。建议将其调整为较短的值，以实现快速故障定位。操作步骤如下：

set session lock_wait_timeout = 1800;  # 30分钟set global lock_wait_timeout = 1800;

这样一来，当出现Waiting for table metadata lock状态时，数据库会在30分钟后自动终止相关进程，从而避免长时间阻塞。

3. 杀死导致阻塞的进程

如果通过调整锁超时阈值仍未解决问题，下一步就是直接清理现有的阻塞进程。可以通过以下命令快速定位并杀死相关进程：

#!/bin/bashmysql -u root -e "show processlist" | grep -i "Locked" > locked_log.txtfor line in `cat locked_log.txt | awk '{print $1}'` do    echo "kill $line;"    done

生成的kill_thread_id.sql文件将包含所有需要杀死的线程ID，执行该脚本即可清除所有阻塞进程：

kill 66402982;kill 66402983;kill 66402986;kill 66402991;...

当然，也可以通过以下命令一行完成：

for id in `mysqladmin processlist | grep -i locked | awk '{print $1}'` do    mysqladmin kill $iddone

注意事项

• 及时修复未提交的事务：在进行DDL操作前，确保所有相关事务都已提交，避免因未提交事务导致Metadata Lock阻塞。
• 定期监控数据库状态：通过设置监控工具（如Percona Monitoring and Management），实时监控数据库连接状态和进程活动，及时发现潜在问题。
• 优化数据库设计：在设计数据库时，尽量减少对Metadata Lock的依赖，避免长时间持有锁的情况。

转载声明

本文最初发布于51CTO博客。如需进一步了解相关技术，建议访问该链接查看完整内容。