MySQL数据库锁等待超时，show
MySQL 执行 SQL 时提示 Lock wait timeout exceeded，通常就是事务等待行锁超时，默认等待时间是 50 秒。
原因多半是另一个事务持有锁未提交或未回滚。
下面直接从现象入手，教你用 show engine innodb status 分析当前锁等待，并逐步定位到具体事务和 SQL。
确认锁等待超时现象
先看报错信息，典型提示是：
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction出现这条报错，说明当前会话在等待某个行锁，超过了 innodb_lock_wait_timeout 设置的时间。
先通过下面命令查看当前等待锁的会话：
SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'LOCK WAIT'\G如果结果为空，再检查所有运行中的事务：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query
FROM information_schema.innodb_trx;这几列分别表示事务 ID、状态、开始时间、MySQL 连接线程 ID 和当前执行语句。
通常能看到两个事务：一个在等待锁，一个在持有锁。
用 show engine innodb status 分析锁等待
执行下面的命令查看详细锁信息，重点看 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 段落：
SHOW ENGINE INNODB STATUS\G在输出里找到 TRANSACTIONS 段落，你会看到类似下面的记录：
---TRANSACTION 213459, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 12345, OS thread handle 140000, query id 56789 ...
UPDATE `orders` SET `status` = 1 WHERE `id` = 100
------- TRX HAS BEEN WAITING 12 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12 page no 3 n bits 80 index `PRIMARY` of table `orders` trx id 213459 lock_mode X locks rec but not gap waiting重点看三处：
LOCK WAIT标明这个事务正在等待锁；MySQL thread id对应该事务所在连接；FOR THIS LOCK TO BE GRANTED下方的行说明了等待哪张表、哪个索引、什么锁类型。
同时往上翻，还有持有锁的事务记录：
---TRANSACTION 213458, ACTIVE 40 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 12340, OS thread handle 139999, query id 56780 ...此时就可以确定 trx_id 为 213458 的事务持有 orders 表 id=100 这行的排他锁，而事务 213459 正在等待它释放锁。
定位到具体 SQL 和连接
拿到 MySQL thread id 后，直接查这个连接正在执行的 SQL：
SELECT * FROM performance_schema.processlist WHERE id = 12340;看到 INFO 字段里就是持有锁事务正在执行的语句。
再结合 information_schema.innodb_trx 里的 trx_started 判断事务持续时间。
若一时看不到具体 SQL，可以启用性能监控来捕获锁等待现场的完整语句：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%events_statements%';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/%';开启后，performance_schema.events_statements_history_long 中能查到对应线程的历史 SQL。
处理锁等待超时的通用避坑原则
先别急着重启数据库。
锁等待超时通常不是数据库崩溃，而是业务逻辑问题。
按下面顺序处理：
- 确认持锁事务是否需要回滚。如果是异常事务，直接执行
KILL 12340;（把 12340 换成持锁连接的线程 ID），或者联系应用侧回滚事务。 - 检查应用是否开启了事务但未提交。比如先
BEGIN后执行了UPDATE，却在 catch 里没写ROLLBACK，这是最常见的锁长时间不释放原因。 - 尽量把事务做短。在事务中不要有外部接口调用、RPC、长查询、大批量更新，减少锁占用时间。
- 调整锁等待超时时间。如果业务偶尔有合理的长事务，可以适当调大参数，但不建议作为常态解决方案：
SET GLOBAL innodb_lock_wait_timeout = 60;
SET SESSION innodb_lock_wait_timeout = 60;修改后注意当前连接重新登录才会生效。
运行中的长查询也要注意，MySQL 5.7 及以上版本若同时存在 DDL 等待，也会表现为锁等待超时。
验证锁是否已释放
处理完持锁事务后，重新执行之前报错的 SQL，确认不再出现 Lock wait timeout exceeded。
再执行一次：
SELECT trx_id, trx_state, trx_mysql_thread_id
FROM information_schema.innodb_trx
WHERE trx_state = 'LOCK WAIT';如果结果为空，说明当前没有锁等待事务。
还想确认连接的持锁情况，可以看：
SHOW PROCESSLIST;检查是否存在 State 为 Waiting for table metadata lock 或 updating 的长时间连接。
这里有一个关键结论：锁等待超时的大部分根因是事务未提交或事务过长，单纯靠重启 MySQL 无法根治。 用 show engine innodb status 配合 information_schema.innodb_trx 能快速定位持锁事务和等待锁事务；
如果是常规行锁，直接处理持锁连接即可；
如果经常出现锁超时，就要从应用的事务设计和 SQL 执行计划入手优化。
建议在业务代码里增加异常回滚，确保事务最终一定提交或回滚，避免下次再遇到同样问题。
如果你后续还遇到锁等待死锁，或同一张表频繁出现锁超时，可以先从慢查询日志和 performance_schema 中找高频更新语句，再针对性加索引或调整事务边界。
