应捕获错误码'1213'并重试2–3次，每次重试前需重新开启事务、使用指数退避延迟，且确保SQL执行顺序统一、事务幂等；超限重试说明存在设计缺陷。
死锁无法彻底避免，但必须让应用在报错 1213 后自动重试 2–3 次，且每次重试前要重新开启事务。
捕获 1213 错误码并重试
MySQL 报出 Deadlock found when trying to get lock 时，PDO 会抛出 PDOException，其 $e->getCode() 是字符串 '1213'（注意不是整数）。只检查这个码才安全，其他如 1205（锁等待超时）虽也常见，但成因和处理策略不同。
- 必须开启
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则execute()失败不会抛异常 - 重试逻辑不能写在事务内部——事务一旦失败，连接状态已不可用，必须
rollback()后再beginTransaction() - 不要用
sleep(1)这类固定延迟，改用指数退避：第 1 次等 50ms，第 2 次 100ms，第 3 次 200ms - 示例判断：
if ($e->getCode() === '1213') { $retryCount++; continue; }
用 DB::transaction() 的内置重试参数
Laravel 的 DB::transaction() 第二个参数就是最大重试次数，它底层已封装了 1213 捕获、回滚、重开事务的完整流程，适合标准场景。
- 传入整数如
3即可，无需手动写循环 - 闭包内所有操作必须是幂等的：比如
decrement('stock')可以重试，但insert()非幂等，需配合唯一索引或业务层判重 - 它不处理
1205或连接类错误（如2006），只专注死锁 - 调用示例：
DB::transaction(function () { ... }, 3)
手动控制重试：加日志、退避、差异化逻辑
当需要记录每次重试耗时、动态调整 SQL 条件、或末次重试前触发告警时，就得绕过 DB::transaction()，自己写 while + beginTransaction()。
- 用引用传递
&$attemptNumber进闭包，可在闭包内感知当前是第几次执行 - 例如首次尝试带版本号校验：
WHERE id = ? AND version = ?；第二次直接覆盖：WHERE id = ? - 每次循环开头必须
DB::beginTransaction()，不能复用旧事务 - 重试上限建议 ≤ 3，超过说明表顺序或索引设计有根本问题，不是靠重试能解决的
为什么统一 SQL 执行顺序能减少死锁
两个事务如果都按 users → orders → payments 顺序更新，就不会形成循环等待；一旦一个按 orders → users，另一个按相反顺序，就极易触发 1213。
- 这不是代码 bug，是并发资源竞争的必然现象
- 所有涉及多表变更的业务，必须在团队内约定并文档化操作顺序
- SELECT … FOR UPDATE 也受此影响：先查 A 表再查 B 表，和先查 B 再查 A，锁的获取路径完全不同
- 事务越长，锁持有时间越久，冲突窗口越大——避免在事务里做 HTTP 请求、文件读写等阻塞操作
真正难的不是写重试逻辑，而是确认哪几条 SQL 在争抢什么资源。PHP 日志只能告诉你“发生了死锁”，具体得看 MySQL 的 SHOW ENGINE INNODB STATUS 输出，里面会明确列出两个事务各自持有哪些锁、等待哪些锁。没这一步，重试只是掩盖问题，不是解决问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
