数据库死锁不是 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 能帮你反推业务场景：
MVM mall 网上购物系统
下载
采用 php+mysql 数据库方式运行的强大网上商店系统，执行效率高速度快，支持多语言，模板和代码分离，轻松创建属于自己的个性化用户界面 v3.5更新： 1).进一步静态化了活动商品. 2).提供了一些重要UFT-8转换文件 3).修复了除了网银在线支付其它支付显示错误的问题. 4).修改了LOGO广告管理,增加LOGO链接后主页LOGO路径错误的问题 5).修改了公告无法发布的问题,可能是打压
- 提取死锁中出现的表名、主键值、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+ 支持自动重试） - 注意：只对幂等操作重试（如扣库存、状态流转），禁止对发短信、写日志等副作用操作盲目重试
