mysql僵死事务需查information_schema.innodb_trx表，以trx_started时间戳为准，超阈值（如300秒）且trx_state非'lock wait'、'committing'，trx_command非'sleep'者即为待清理对象。
如何识别 MySQL 中的僵死事务
MySQL 的僵死事务（即长时间未提交/回滚的事务）主要藏在 INFORMATION_SCHEMA.INNODB_TRX 表里，关键指标是 TRX_STARTED 时间戳。只要当前时间减去它超过阈值（比如 300 秒），就大概率是异常事务。
注意：仅靠 TRX_STATE = 'RUNNING' 不够——很多长查询或大事务也处于该状态但属正常；必须结合 TRX_STARTED 和业务实际容忍时长判断。
-
TRX_MYSQL_THREAD_ID是 kill 的目标线程 ID，不是PROCESSLIST.ID，但二者通常一致（5.7+ 之后已对齐） - 避免误杀：跳过
TRX_COMMAND = 'Sleep'或TRX_STATE = 'LOCK WAIT'的事务（它们可能是等待锁，而非僵死） - 不要查
SHOW PROCESSLIST——它不暴露事务启动时间，且无法区分显式事务和自动提交语句
用 SQL 查出待清理的僵死事务 ID
以下 SQL 返回所有运行超 300 秒、且非 Sleep / LOCK WAIT 的事务线程 ID：
SELECT TRX_MYSQL_THREAD_ID
FROM INFORMATION_SCHEMA.INNODB_TRX
WHERE (UNIX_TIMESTAMP() - UNIX_TIMESTAMP(TRX_STARTED)) > 300
AND TRX_STATE NOT IN ('LOCK WAIT', 'COMMITTING')
AND TRX_COMMAND != 'Sleep';
这个查询要加在 Shell 脚本里执行，结果直接用于后续 KILL。别用 SELECT *——字段多、网络开销大，且脚本只需线程 ID。
- 阈值 300 秒可按需调整，线上建议从 600 开始试，避免误伤批量导入类任务
- 务必加
AND TRX_COMMAND != 'Sleep'：否则会把空闲连接（autocommit=1 且没操作）也当僵死事务 - 如果用 MySQL 8.0+，可加
AND TRX_ISOLATION_LEVEL != 'READ COMMITTED'辅助过滤（某些低隔离级事务更易滞留）
Shell 脚本实现自动检测与安全 kill
核心逻辑是：连库查 ID → 逐个 KILL → 记录日志。不能一次性 KILL 多个（MySQL 不支持逗号分隔的 KILL）。
示例脚本片段（保存为 cleanup_zombie_trx.sh）：
#!/bin/bash
MYSQL_CMD="mysql -uadmin -p'xxx' -h127.0.0.1 -P3306 --skip-column-names -B"
THRESHOLD=300
<p>for tid in $($MYSQL_CMD -e "
SELECT TRX_MYSQL_THREAD_ID
FROM INFORMATION_SCHEMA.INNODB_TRX
WHERE (UNIX_TIMESTAMP() - UNIX_TIMESTAMP(TRX_STARTED)) > $THRESHOLD
AND TRX_STATE NOT IN ('LOCK WAIT', 'COMMITTING')
AND TRX_COMMAND != 'Sleep'
"); do
if [ -n "$tid" ]; then
echo "$(date): killing zombie trx $tid" >> /var/log/mysql/zombie_kill.log
$MYSQL_CMD -e "KILL $tid" 2>>/var/log/mysql/zombie_kill.log
fi
done</p>
- 必须用
--skip-column-names -B，否则输出带列头和制表符，for循环会错读 -
KILL命令失败（如权限不足、线程已退出）会写入日志，但脚本不应中断——加2>>捕获错误即可 - 不要用
KILL CONNECTION：对事务无意义；KILL（等价于KILL QUERY）已足够终止其当前语句并回滚事务
部署与防误操作要点
脚本本身不危险，危险的是执行时机和权限。生产环境必须限制三件事：
- MySQL 账户只赋予
PROCESS和REPLICATION CLIENT权限（KILL需CONNECTION ADMIN或SUPER，但 8.0.12+ 推荐用CONNECTION ADMIN替代SUPER） - crontab 中设置间隔至少 5 分钟：
*/5 * * * * /path/cleanup_zombie_trx.sh，太频繁可能干扰正在恢复的事务 - 首次上线前，先用
echo "KILL $tid"替代真实KILL，跑一天看日志是否命中预期事务
最常被忽略的是：某些 ORM（如 Django 的 atomic 块）或连接池（如 HikariCP 的 leakDetectionThreshold）会在应用层触发事务超时，但 MySQL 层未必感知——这类场景得靠应用日志联动排查，单靠数据库脚本无法覆盖。
