MySQL 错误 1213：InnoDB 发现死锁，被选中的那个事务整笔回滚

报 1213 之后，回滚了什么、怎么重试

• 整事务回滚：官方 InnoDB Error Handling 写明，死锁会让 InnoDB 回滚整个事务；锁等待超时（1205）默认只回滚当前语句。（InnoDB Error Handling）
• 重试整个事务：错误参考原文是 “run all the operations in this transaction again”。被回滚的一方已经释放全部锁，另一方通常能拿到锁；重跑时可能要再等一会儿，但一般不会马上再死锁一次。
• 谁被挑中：死锁检测开启时，InnoDB 尽量挑改动行数更少的事务回滚。（Deadlock Detection）

应用如果只捕获 1213 后重试「最后一条 SQL」，事务前面已经回滚掉的写入不会自动回来。要按业务边界重开整笔事务。

1213 和 1205 怎么区分

innodb_deadlock_detect=ON（默认）时，真正的死锁不会拖到 1205：InnoDB 会先拆环并报 1213。只有关掉死锁检测，死锁里的事务才可能靠锁等待超时结束。（Deadlock Detection、InnoDB 系统变量 innodb_lock_wait_timeout）

先看 LATEST DETECTED DEADLOCK

SHOW ENGINE INNODB STATUS\G

这一段会写出参与死锁的事务、各自持有和等待的锁、以及哪一个被选为牺牲者。读法与复现脚本见长文：MySQL 死锁 1213 / 间隙锁实测。

官方还提醒：若出现 TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH，表示 wait-for 列表达到 200 个事务（或需要查看超过 100 万把锁），也会被当作死锁处理并回滚正在检查的事务。（Deadlock Detection）

现场只读：谁在等锁、事务开了多久

SELECT waiting_pid, waiting_query, blocking_pid, blocking_query
FROM sys.innodb_lock_waits;

SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_s,
       trx_mysql_thread_id, trx_query
FROM information_schema.INNODB_TRX
ORDER BY trx_started;

官方建议怎么少死锁

• 让不同事务 / 应用的加锁顺序一致（LOCK TABLES、SELECT ... FOR UPDATE 等）。（错误参考原文）
• 事务里从第一次改数据到 COMMIT 之间少做事，锁持有时间尽量短、锁住的行尽量少。（InnoDB Error Handling）
• 高并发下若死锁检测本身成为瓶颈，可以关 innodb_deadlock_detect，改靠 innodb_lock_wait_timeout；这是吞吐取舍，不是「一关就没事」。（Deadlock Detection）

常见问题

相关错误码

• 1205 · Lock wait timeout exceeded
• 1040 · Too many connections
• 1045 · Access denied for user

• MySQL 死锁 1213：间隙锁 + 插入意向锁实测与 INNODB STATUS 读法
• MySQL 1205 锁等待超时：阻塞链实测

← 返回MySQL 错误码速查

下一步

价格以对应页面当前标价为准。