数据库死锁不是 PHP 本身的问题，而是多个事务并发操作时争夺资源导致的循环等待。PHP 应用只是触发者，排查重点在 MySQL（或其他数据库）层面，配合应用层日志和代码逻辑分析。
查看数据库死锁日志
MySQL 默认开启死锁检测，但需确认是否记录详细信息：
- 执行 SHOW ENGINE INNODB STATUS\G，查找 LATEST DETECTED DEADLOCK 区域，里面会显示最近一次死锁的两个事务、各自持有的锁、等待的锁、SQL 语句及事务 ID
- 确保 innodb_print_all_deadlocks = ON（写入 error log），避免只保留最后一次死锁信息
- 检查 MySQL 错误日志路径：SHOW VARIABLES LIKE 'log_error';
定位触发死锁的 PHP 代码路径
死锁日志中的 SQL 能帮你反推业务场景：
- 提取死锁中出现的表名、主键值、WHERE 条件，结合项目代码搜索对应 DAO 方法或 ORM 操作（如 Laravel 的
updateOrCreate()、ThinkPHP 的save()） - 重点关注“先查后更”、“批量更新多行”、“事务中跨表操作顺序不一致”的逻辑——比如 A 事务按 user_id 升序更新，B 事务按降序更新，极易形成锁等待环
- 在关键事务开始前加日志：error_log("[TX] Start order_update, uid={$uid}, order_ids=".json_encode($ids));
优化事务与 SQL 避免死锁
多数死锁可通过设计规避，而非仅依赖重试：
立即学习“PHP免费学习笔记（深入）”；
- 缩短事务范围：把非数据库操作（如 HTTP 请求、文件写入）移出事务块；用 SELECT ... FOR UPDATE 前确保 WHERE 条件能命中索引，避免锁整张表
- 统一操作顺序：多个事务更新多张表时，始终按相同顺序（如先 users 表，再 orders 表，最后 logs 表）
- 避免在事务中使用 SELECT * FROM table ORDER BY id DESC LIMIT 1 这类无索引排序 + LIMIT，可能引发间隙锁扩散
- 对高频更新字段（如库存、计数器），考虑用 UPDATE table SET stock = stock - 1 WHERE id = ? AND stock >= 1 替代先查再判再更
应用层增加死锁感知与重试机制
无法完全避免时，让 PHP 主动处理比让 MySQL 报错更友好：
- 捕获 PDO 或 mysqli 的错误码：1213（Deadlock found when trying to get lock），对关键业务做 2~3 次指数退避重试
- Laravel 中可在 DB::transaction() 外包一层重试逻辑，或使用
DB::transaction(..., $attempts)（v8.0+ 支持自动重试） - 注意：只对幂等操作重试（如扣库存、状态流转），禁止对发短信、写日志等副作用操作盲目重试
