直接查 SHOW OPEN TABLES WHERE In_use > 0，结果非空即表示有表被锁；In_use > 0 表示表被打开未释放，Name_locked = YES 表示表名被 DDL 锁定。
怎么一眼看出表是不是被锁了？
直接查 SHOW OPEN TABLES WHERE In_use > 0，只要结果非空，说明当前有表正被加锁使用。注意不是“正在被修改”，而是“被打开且未释放”——比如一个事务里执行了 SELECT ... FOR UPDATE 但没提交，这张表就会持续出现在结果里。In_use > 0 是硬指标，Name_locked 字段为 YES 则代表表名本身被 DDL 操作（如 RENAME TABLE）占着，连查询都可能卡住。
为什么 UPDATE 看似只改一行，却锁了整张表？
核心原因就一个：WHERE 条件字段没索引，或索引失效。InnoDB 行锁本质是锁索引，没索引就只能全表扫描，而 RR 隔离级别下会用 Next-Key Lock 把所有扫描过的记录+间隙全锁住——看起来就是“锁表”。
- 典型错误：对
UPDATE products SET status='inactive' WHERE category='electronics'操作，但category字段无索引 - 验证方法：执行
EXPLAIN看是否走type=ALL（全表扫描） - 陷阱：即使有索引，如果用了函数（如
WHERE UPPER(name)='ABC'）或隐式类型转换（如字符串字段传数字），索引也会失效
如何快速定位谁在堵路？
别只看 SHOW PROCESSLIST，它只告诉你“谁在等”，不告诉你“等什么”。真正有用的组合是：
-
SELECT * FROM information_schema.INNODB_TRX：看哪些事务长期没提交（重点关注trx_started和trx_state） -
SELECT * FROM information_schema.INNODB_LOCK_WAITS：直接看到等待关系，哪条事务在等哪条事务的锁 - 终极命令：
SHOW ENGINE INNODB STATUS\G，重点翻到TRANSACTIONS和LATEST DETECTED DEADLOCK段，里面连 SQL、锁类型、事务 ID 都给你列清楚了
注意：INNODB_LOCKS 在 MySQL 8.0.24+ 已废弃，改用 performance_schema.data_locks；但线上若还是 5.7 或 8.0 早期版本，它仍是关键入口。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
杀进程前必须确认的三件事
KILL 不是万能解药，乱杀可能让事务回滚更久、甚至拖垮主从同步。动手前务必确认：
- 该线程是否属于业务关键链路（比如订单支付回调事务），盲目 KILL 可能导致状态不一致
- 它的
State是否真是Locked，还是只是Updating或Sending data（后者可能是慢查询，不是锁问题） - 有没有更温和的干预方式：比如先执行
SET innodb_lock_wait_timeout = 5缩短等待时间，让阻塞方更快超时退出
最常被忽略的一点：MyISAM 引擎压根没有行锁，所有写操作都是表级锁，所以一旦出现“锁表现象”，先用 SHOW CREATE TABLE 确认引擎类型——别在 InnoDB 的排查路径里死磕 MyISAM 表。
