优先查INNODB_TRX定位活跃事务状态，再联查INNODB_LOCK_WAITS确认阻塞链，辅以INNODB_LOCKS分析锁类型；SHOW FULL PROCESSLIST仅用于验证线程实时状态，不可单独依赖。
直接查 INNODB_TRX 和 SHOW FULL PROCESSLIST 就能定位阻塞源，但盲目 KILL 可能导致事务回滚或应用异常——得先确认它是否还在执行、有没有未提交的变更。
查哪些表能快速定位阻塞进程
MySQL 5.7 及以上版本，优先用这三张 INFORMATION_SCHEMA 表组合判断：
-
INNODB_TRX：看当前活跃事务，重点关注trx_state（是否为LOCK WAIT）、trx_started（运行时长）、trx_mysql_thread_id（对应线程 ID） -
INNODB_LOCK_WAITS：直接关联等待方和阻塞方，requesting_trx_id是被卡住的事务，blocking_trx_id是罪魁祸首 -
INNODB_LOCKS（5.7）或performance_schema.data_locks（8.0+）：确认锁类型和锁定的具体行/间隙，避免误判是元数据锁（MDL）还是行锁
注意：INNODB_LOCKS 和 INNODB_LOCK_WAITS 在 MySQL 8.0.1 中已被移除，8.0+ 必须改用 performance_schema.data_locks 和 performance_schema.data_lock_waits。
用 SHOW FULL PROCESSLIST 辅助验证状态
该命令不依赖事务引擎，能直观看到线程的实时状态，关键看三列：
-
State：值为Locked或Waiting for table metadata lock说明卡在表级锁；Updating/Deleting且Time很大，大概率是慢查询持锁不放 -
Info：显示正在执行的 SQL，可判断是否含FOR UPDATE、LOCK TABLES或无 WHERE 条件的全表更新 -
Command：若为Sleep但Time持续增长，极可能是应用端开启事务后没提交（autocommit=0且忘了COMMIT）
不要只信 State = "Locked" —— InnoDB 行锁不会让状态变成 Locked，那通常是 MyISAM 表锁或元数据锁（MDL）的表现。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
终止进程前必须检查的三个条件
KILL 不是万能解药，执行前务必确认：
- 目标线程是否属于你可控的应用服务？比如
User是app_user而非root，避免误杀监控或备份任务 - 该事务是否已修改数据但未提交？查
INNODB_TRX的trx_isolation_level和trx_rows_modified，若后者 > 0，KILL会触发隐式回滚，可能破坏业务一致性 - 是否在从库上操作？
KILL主库线程不影响复制，但若在从库上干掉 SQL 线程（Command = 'Connect'且db = NULL），会导致复制中断
安全做法是优先用 KILL QUERY thread_id 终止当前语句，保留连接和事务上下文；仅当确认连接已僵死，才用 KILL CONNECTION thread_id。
为什么 SHOW OPEN TABLES WHERE In_use > 0 有时查不到阻塞
这条命令只反映 LOCK TABLES 语句加的显式表锁（如 LOCK TABLES t1 READ），对 InnoDB 的行锁、间隙锁、意向锁完全无效。常见误解是：“In_use = 0 就没锁”——错。真正的阻塞往往来自：
- RR 隔离级别下
SELECT ... FOR UPDATE持有的临键锁（Next-Key Lock），SHOW OPEN TABLES压根不感知 - 外键约束触发的隐式锁，或二级索引更新引发的聚簇索引锁扩散
- DDL 操作（如
ALTER TABLE）持有的元数据锁（MDL），需查performance_schema.metadata_locks
所以它只能作为辅助线索，绝不能作为“无锁”的依据。真正要抓阻塞，永远以 INNODB_TRX + INNODB_LOCK_WAITS（或 8.0+ 对应表）为第一手证据。
