最有效方式是kill线程id，需通过information_schema.innodb_trx定位trx_state='running'且trx_query is null、运行超60秒的事务，取trx_mysql_thread_id执行kill，事后验证innodb_trx是否清空。
直接 kill 线程 ID 是最有效的方式，但必须先准确定位到真正“卡住”的事务线程，不能只看 SHOW PROCESSLIST 中的 Sleep 状态。
查事务不能只用 SHOW PROCESSLIST
因为未提交事务可能处于 RUNNING 状态但实际没在执行 SQL（比如等待应用层逻辑），SHOW PROCESSLIST 只显示连接状态，不反映事务真实活跃性。真正要查的是 information_schema.innodb_trx 表：
-
trx_state = 'RUNNING'且trx_query IS NULL：事务空转中，很可能已卡住 - 用
TIMESTAMPDIFF(SECOND, trx_started, NOW())算运行秒数，超过 60 秒就值得警惕 - 结合
trx_mysql_thread_id和information_schema.processlist关联查登录用户、主机、命令类型，排除运维或监控类连接
KILL 命令必须作用于线程 ID，不是事务 ID
innodb_trx.trx_id 是 InnoDB 内部事务编号，KILL 不认它；真正要杀的是 trx_mysql_thread_id 字段值：
- 执行
KILL 45;（假设查到线程 ID 是 45）后，MySQL 会立即中断该连接，触发隐式回滚 - 回滚耗时取决于已修改的行数和 undo log 大小，大事务可能卡住几秒到几分钟，期间
SHOW PROCESSLIST会显示Rolling back - 不要重复执行
KILL—— 如果第一次没返回错误，说明命令已接收，再发一次可能报Unknown thread id
误杀风险高，先确认再动手
有些“长时间运行”是合理业务行为（如报表导出、批量导入），盲目 kill 会导致数据不一致：
- 检查
trx_query字段，如果是SELECT ... FOR UPDATE或大范围UPDATE，需联系业务方确认是否可中断 - 若事务来自 DBA 工具（如 DBeaver、Navicat），且
trx_query为空、COMMAND是Sleep、TIME超过 300 秒，基本可判定为用户忘记提交 - 生产环境建议加条件过滤：只查
trx_isolation_level = 'REPEATABLE-READ'且非root用户的连接，降低误操作概率
最易被忽略的一点：kill 后必须立刻验证回滚是否完成 —— 查 information_schema.innodb_trx 是否清空，而不是只看 processlist 里有没有那个 ID。因为线程 ID 可能被复用，而事务残留会导致后续 DDL（如 TRUNCATE、ALTER TABLE）持续阻塞。
