MySQL死锁错误为“Deadlock found when trying to get lock; try restarting transaction”，是InnoDB因循环等待主动回滚代价小的事务；需通过SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK定位加锁顺序冲突，并按主键升序、缩小锁范围、索引优化及幂等重试来规避。

死锁错误长什么样？直接看关键信息

MySQL 报出死锁时，客户端收到的典型错误是：Deadlock found when trying to get lock; try restarting transaction。这不是连接失败或语法错误，而是事务在等待对方释放锁时，双方形成循环等待，InnoDB 主动干掉其中一个事务（通常是回滚代价更小的那个）来打破僵局。

重点不是“为什么报错”，而是“谁被干掉了”“为什么是它”“怎么避免再被干掉”。错误日志里会附带 SHOW ENGINE INNODB STATUS 的最近死锁详情，必须去看——它会明确列出两个事务各自的 SQL、持有的锁、等待的锁、加锁顺序。

查死锁现场：用 SHOW ENGINE INNODB STATUS 定位根因

执行该命令后，在输出中找到 LATEST DETECTED DEADLOCK 区域。里面包含两段事务快照，每段含：

• TRANSACTION ID 和事务开始时间
• mysql tables in use 和 locked tables —— 涉及哪些表
• LOCK WAIT 行 —— 当前卡在哪条 SQL、等哪个索引上的哪种锁（如 RECORD LOCKS space id 123 page no 456 n bits 72）
• HOLDS THE LOCK(S) —— 已持有哪几个记录锁或间隙锁
• WAITING FOR THIS LOCK TO BE GRANTED —— 正在等对方释放什么锁

对比两个事务的加锁顺序，就能看出是否因为 A 先锁 X 再锁 Y，B 先锁 Y 再锁 X 导致冲突。这是最常复现的模式。

避免死锁的实操原则：顺序、范围、粒度

死锁无法 100% 消除，但可大幅降低概率。核心是让并发事务以**相同顺序访问资源**，并**减少锁持有时间与范围**：

• 所有涉及多行更新/删除的业务逻辑，强制按主键（或唯一索引）升序处理 ID 列表，例如先 SELECT ... ORDER BY id ASC 拿到有序 ID，再按序 UPDATE
• 避免在事务中执行非确定性操作（如调用 NOW()、子查询慢、外部 HTTP 请求），防止事务拖长、锁住更多行
• 把 SELECT ... FOR UPDATE 放在事务靠前位置，且只锁定真正需要修改的行；不要用 SELECT * FROM t WHERE status = 'pending' FOR UPDATE 这种宽泛条件
• 检查索引覆盖：如果 WHERE 条件没走索引，InnoDB 会升级为表级意向锁甚至全表扫描加锁，极大增加冲突面

应用层重试策略不能乱写

遇到死锁错误，必须重试整个事务，但重试逻辑要克制：

• 只对 Deadlock found when trying to get lock 错误重试，别把 Lock wait timeout exceeded 或主键冲突也混进来
• 最多重试 2–3 次，每次加随机退避（如 10ms–100ms），避免雪崩式重试压垮数据库
• 重试前确认业务幂等性：比如扣库存场景，需先查当前余量再扣，而不是无条件 UPDATE stock SET num = num - 1

try {
  await connection.beginTransaction();
  await connection.execute('UPDATE orders SET status = ? WHERE id = ?', ['shipped', orderId]);
  await connection.execute('INSERT INTO shipments (...) VALUES (...)', [...]);
  await connection.commit();
} catch (err) {
  if (err.message.includes('Deadlock found')) {
    // 记录日志 + 随机延迟 + 递归重试（带计数限制）
    await sleep(Math.random() * 90 + 10);
    return retryPlaceShipment(orderId, attempt + 1);
  }
  throw err;
}

真正难的不是捕获错误，而是当死锁频繁发生时，说明底层数据访问模式存在结构性问题——比如高并发抢同一行（如账户余额）、或批量任务未分片导致锁范围过大。这时候光靠重试和索引优化不够，得重构访问路径。