可通过INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCK_WAITS查出死锁中持锁与等待的事务；若无LOCK WAIT状态，说明死锁已被自动回滚；KILL前需确认线程活跃性、SQL可中断性及归属应用，优先用KILL thread_id并验证退出。
怎么查出哪个进程在导致死锁
MySQL本身不直接暴露“谁锁了谁”的完整链条，但INFORMATION_SCHEMA.INNODB_TRX和INFORMATION_SCHEMA.INNODB_LOCK_WAITS能拼出关键线索。先连上数据库，执行：
SELECT trx_id, trx_mysql_thread_id, trx_query, trx_state, trx_started FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT';
这能揪出正在等锁的事务。再关联INNODB_LOCK_WAITS，就能看到它在等哪个blocking_trx_id——那个就是持锁不放的“真凶”。注意：如果查不到LOCK WAIT状态，说明死锁已被InnoDB自动检测并回滚了其中一个事务，此时表已解锁，不用手动干预。
kill掉线程前必须确认的三件事
别一看到trx_mysql_thread_id就KILL，容易误杀正常长事务。务必核对：
-
这个线程是否还在活跃：查
SHOW PROCESSLIST，看对应ID的State是不是Locked或Waiting for table metadata lock，而不是Sleep -
它执行的SQL是否可中断：比如
UPDATE中途KILL会回滚，但大事务回滚本身也耗时；而ALTER TABLE被杀可能留下临时表或元数据不一致 -
它归属哪个应用或DBA操作：检查
User和Host字段，避免干掉监控、备份或运维脚本的连接
用KILL命令终止指定线程的正确姿势
KILL分两种：普通KILL （请求客户端断开）和强制thread_idKILL QUERY （只终止当前语句，保留连接）。多数死锁场景该用前者：thread_id
KILL 12345;
执行后立刻再跑SHOW PROCESSLIST确认该ID消失。如果线程状态变成Killed却迟迟不退出，说明它正在回滚大事务——这时只能等，强行重启MySQL反而风险更高。注意：KILL对SYSTEM USER线程（如复制IO线程）无效，也不能杀掉自己当前连接的thread_id。
为什么有时KILL了还卡着？常见陷阱
不是所有“卡住”都是死锁，很多是元数据锁（MDL）、表锁或长事务阻塞。典型假象：
- 执行
ALTER TABLE时被另一个SELECT阻塞：那是MDL锁，KILL那个SELECT线程才有效，不是ALTER发起者 - 事务里执行了
START TRANSACTION但没提交，后面所有操作都算在同一个事务里——查INNODB_TRX时trx_query可能是NULL，得靠trx_started时间判断陈旧度 - 使用了
READ COMMITTED隔离级别却仍遇到锁等待：InnoDB行锁在RC下仍存在，只是不加间隙锁，不代表完全无锁
真正难处理的是嵌套调用或ORM自动生成的隐式事务，它们让锁持有者难以追溯。这时候得结合应用日志和慢查询日志交叉比对，而不是只盯着MySQL内部视图。
