MySQL 死锁排查实战：从“Killed”状态到“ROLLING BACK”的深度解析
在数据库运维中，死锁是常见的“拦路虎”。本文基于一次真实的线上故障排查，深入剖析了 MySQL 死锁的排查流程，特别是针对
Killed状态和ROLLING BACK状态的深度解读，帮助 DBA 和开发者快速定位并解决死锁问题。
一、 死锁与锁等待：别傻傻分不清
在排查问题前，首先要明确两个概念：死锁（Deadlock）和锁等待（Lock Wait）。
- 死锁（Deadlock）：两个或多个事务互相持有对方需要的锁，形成循环等待。MySQL 会自动检测并回滚其中一个事务，错误信息通常包含
Deadlock found when trying to get lock。 - 锁等待（Lock Wait）：一个事务尝试获取某个资源的锁时，由于该资源被另一个事务长时间占用，导致等待超过了设定的时间阈值（如
innodb_lock_wait_timeout）。最终事务因等待超时而失败，提示Lock wait timeout exceeded; try restarting transaction。
结论：如果你的错误日志是后者，说明当前事务只是被“饿死”了，而非陷入了死循环。
二、 实战排查：SHOW FULL PROCESSLIST 与 KILL 命令
当发现数据库响应变慢或出现锁等待超时，第一步通常是查看当前连接状态。
1. 查看进程列表
SHOWFULLPROCESSLIST;重点关注以下几列：
- Id：线程的唯一标识符，用于后续的
KILL命令。 - Time：线程处于当前状态的时长（秒）。长时间运行的查询或事务更可能引发锁问题。
- State：线程的当前状态。例如
Locked、Waiting for table metadata lock等状态都直接表明线程可能在等待锁。 - Info：显示正在执行的 SQL 语句。
2. 终止可疑进程
确认了可疑进程的线程 ID 后，使用KILL命令终止它：
KILL<线程ID>;执行后，该连接会被终止，其正在执行的事务会被回滚，从而释放它持有的锁。
三、 深度解析：为什么状态是“Killed”但进程还在？
执行KILL命令后，通过SHOW PROCESSLIST查看，有时会发现进程状态显示为Killed，但该进程并未立即消失，甚至可能持续很长时间。
核心原因：MySQL 的KILL命令并非“立即枪毙”，而是设置了一个终止标志。线程在执行过程中会定期检查这个标志，如果发现被标记为终止，则会中止当前操作并开始清理工作（如事务回滚、释放临时表等）。
为什么“杀不死”？
- 大事务回滚（最常见）：如果你终止了一个正在执行的大事务（如删除/更新百万行数据），MySQL 为了保证数据一致性，必须先将已修改的数据回滚。这个过程可能非常耗时，期间进程状态会显示为
Killed，直到回滚完成才会真正消失。 - 锁等待阻塞：如果该进程正在等待某个锁（如行锁、元数据锁），它必须等到锁被释放后，才能执行“检查终止标志”的逻辑。在等待期间，它无法响应
KILL命令，所以会一直挂着。 - 系统资源瓶颈：如果服务器 I/O 性能极差或 CPU 负载过高，回滚操作或清理临时文件的速度会非常慢，导致进程长时间处于
Killed状态。
四、 进阶排查：INNODB_TRX 与 INNODB_LOCK_WAITS
当简单的KILL无法解决问题时，需要深入 InnoDB 内部查看事务和锁的状态。
1. 查看当前事务状态
SELECT*FROMinformation_schema.INNODB_TRX;重点关注trx_state字段：
- RUNNING：事务正在运行。
- LOCK WAIT：事务正在等待锁。
- ROLLING BACK：事务正在回滚。
- COMMITTING：事务正在提交。
2. 查看锁等待关系
SELECT*FROMinformation_schema.INNODB_LOCK_WAITS;这张表记录了锁的等待关系，可以明确是哪个事务（blocking_trx_id）在阻塞哪个事务（requesting_trx_id）。
五、 核心场景：INNODB_TRX 显示 ROLLING BACK，但 INNODB_LOCK_WAITS 为空
这是本文要解决的核心问题。当你在INNODB_TRX中看到事务状态为ROLLING BACK，但INNODB_LOCK_WAITS表为空时，意味着什么？
结论：事务正在回滚过程中，并未在等待其他锁，而是正在执行回滚操作本身。INNODB_LOCK_WAITS表主要记录的是锁等待关系。当它为空时，表明当前数据库中没有事务因为拿不到锁而处于等待状态。你看到ROLLING BACK状态的事务，是一个正在进行回滚操作的事务。它可能正在撤销已经完成的数据修改，这个过程中它持有必要的锁以确保数据一致性，但并未被阻塞。
处理建议
耐心等待：如果回滚的事务之前修改了大量数据（例如，更新或删除了数十万行），回滚过程会非常耗时。这是最稳妥的做法，强行中断可能导致数据文件损坏。
监控进度：定期执行以下查询，观察事务的
trx_rows_modified等字段值的变化。如果数值在持续减小，说明回滚正在缓慢进行。SELECTtrx_id,trx_state,trx_started,trx_rows_locked,trx_rows_modifiedFROMinformation_schema.INNODB_TRXWHEREtrx_state='ROLLING BACK';检查系统负载：如果服务器磁盘 I/O 性能差或 CPU 负载过高，会显著降低回滚速度。优化系统资源可以加速回滚过程。
六、 总结与预防
- 应急处理：对于
ROLLING BACK状态的事务，不要再次执行KILL或重启数据库。这通常是大事务回滚的正常现象，强行中断风险极高。 - 根本预防：
- 避免大事务：将大批量数据操作拆分成多个较小批次进行。
- 优化索引：确保数据操作语句能高效执行，减少单次事务的锁定时间和范围。
- 统一加锁顺序：让不同的事务按照相同的顺序访问表和行，这是预防死锁最有效的方法。
通过以上步骤，你可以清晰地定位 MySQL 死锁或锁等待问题的根源，并采取正确的应对措施。
