MySQL 5.7 的 sys.innodb_lock_waits 视图不可靠，因其底层 INNODB_LOCK_WAITS 字段残缺、blocking_trx_id 常为0或无效，且 blocking_thread 易指向已结束事务；必须依赖 SHOW ENGINE INNODB STATUS 和 INFORMATION_SCHEMA.INNODB_TRX 手动分析锁链。
MySQL 5.7 的 sys 库不提供死锁源头的直接定位能力，不能依赖 sys.innodb_lock_waits 或类似视图做准确阻塞链分析。
为什么 sys.innodb_lock_waits 在 5.7 中不可靠
sys.innodb_lock_waits 是基于 INNODB_LOCK_WAITS 构建的视图，而 MySQL 5.7 的 INNODB_LOCK_WAITS 表字段残缺（缺少 blocking_trx_id 真实值）、关联不稳定，常返回空或错误 blocking 关系。实测中该视图可能显示“有等待”，但 blocking_thread 字段为 NULL 或指向已结束事务，无法反映真实持有者。
常见错误现象：SELECT * FROM sys.innodb_lock_waits\G 输出里 blocking_query 为空、blocking_trx_id 为 0 或不存在于 INNODB_TRX 中。
- 它在 5.7 中本质是“装饰性视图”，不是诊断依据
- 官方文档明确标注：该视图在 5.7 中仅作兼容保留，不保证数据一致性
- 若你看到它返回结果，必须用
SHOW ENGINE INNODB STATUS\G交叉验证
替代方案：用 INFORMATION_SCHEMA.INNODB_TRX + 手动关联锁
真正有效的起点是 INNODB_TRX，筛选出状态异常的事务，再人工补全锁链：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 先查所有未提交且疑似卡住的事务：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT' OR (trx_state = 'RUNNING' AND COMMAND = 'Sleep') - 对每个
trx_id，去INNODB_LOCKS查它申请的锁：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS WHERE lock_trx_id = 'xxx' - 再根据
lock_space、lock_page、lock_rec组合，反向搜索谁在相同位置持锁：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS WHERE lock_space = ? AND lock_page = ? AND lock_rec = ? AND lock_trx_id != 'xxx'
这个过程无法自动化，因为 5.7 缺乏唯一可靠的锁位置标识字段；lock_id 是临时字符串，不能跨查询复用。
必须配合 SHOW ENGINE INNODB STATUS 看实时快照
当 INNODB_LOCK_WAITS 失效时，SHOW ENGINE INNODB STATUS\G 是唯一权威来源——它的 TRANSACTIONS 段落会列出每个活跃事务的完整锁信息，LATEST DETECTED DEADLOCK 段落则精确给出两个事务的持锁/等锁记录，包括 SQL、索引名、行物理位置（space id/page number/record）。
- 重点看
*** (1) TRANSACTION:和*** (2) TRANSACTION:下的locks held与locks waiting for - 注意输出末尾的
WE ROLL BACK TRANSACTION提示，被回滚的事务 ID 就是死锁中“代价更低”的那个，但其线程往往仍挂在PROCESSLIST里 - 该命令输出是瞬态快照，需立刻复制保存，刷新后即丢失
KILL 前必须确认 thread_id 来源是否可信
从 INNODB_TRX.trx_mysql_thread_id 获取的 ID 才能用于 KILL CONNECTION；不要从 sys.innodb_lock_waits 的 blocking_thread 字段取值，它在 5.7 中经常错位。
- 验证方式：
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = ?，确认状态非Sleep且Time > 60 - 如果
PROCESSLIST查不到对应 ID，说明该事务已结束，INNODB_TRX记录尚未清理，此时 KILL 无意义 - 禁止对
system user或Connect状态的线程执行 KILL，尤其是主从复制线程
最易被忽略的一点：5.7 中事务 ID（trx_id）和连接 ID（thread_id）不是一一映射的——一个连接可开启多个事务，trx_mysql_thread_id 只表示“最近一次启动该事务的连接”，但连接可能早已关闭。所以 KILL 的目标永远是 thread_id，不是 trx_id。
