死锁主因是业务代码高并发下加锁顺序不一致、锁持有时间过长、事务边界不规范；应统一资源访问顺序、缩短事务生命周期、优化索引与锁类型，并实现自动重试与日志监控。
Hyperf 应用中出现数据库死锁，本质不是框架的问题，而是业务代码在高并发下对数据库资源的争抢方式不合理。核心在于：事务内加锁顺序不一致、锁持有时间过长、未按规范使用事务边界。只要控制好这三点，死锁就能大幅降低。
统一资源访问顺序
这是预防死锁最有效、最易落地的手段。多个事务若以不同顺序操作同一组记录（比如先更新用户再更新订单，另一个却先订单后用户），极易触发循环等待。
- 对涉及多表或多个主键的操作，约定固定顺序：例如“总是按 ID 升序处理”“总是先 account 表，再 order 表，最后 log 表”
- 在 DAO 层或 Service 方法入口处，对输入 ID 数组做 sort() 处理，确保每次执行时锁行顺序一致
- 避免在循环中逐条开启事务更新；改用单事务 + 批量语句（如 INSERT ... ON DUPLICATE KEY UPDATE 或 UPDATE ... WHERE id IN (...)）
缩短事务生命周期
锁是事务持有的，事务越长，锁就挂得越久，别人等待的时间就越长，死锁概率自然上升。
- 把非数据库操作（如 HTTP 调用、文件写入、日志记录）全部移出事务块，只保留真正需要原子性的 DB 操作
- 避免在事务中 sleep()、等待协程结果、或调用阻塞型外部接口
- 使用 Hyperf 的 @Transactional 注解时，明确指定 isolation 和 timeout，例如：timeout=5 可防止事务卡死太久
合理使用锁类型与索引
InnoDB 死锁常和间隙锁（Gap Lock）、Next-Key Lock 相关，尤其在范围查询 + 插入场景下（如金额区间 FOR UPDATE 后 INSERT）。这类死锁不容易从代码逻辑一眼看出，但可通过索引优化规避。
- 确保 WHERE 条件走唯一索引或主键，避免全表扫描或范围锁扩大。例如用 WHERE id = ? 而非 WHERE status = ?（没索引时会锁整张表）
- 对高频并发更新字段（如库存、余额），单独建索引，减少锁冲突面
- 必要时关闭间隙锁：将事务隔离级别降为 READ-COMMITTED（需评估幻读风险），或在 SQL 中显式加 SELECT ... LOCK IN SHARE MODE 替代 FOR UPDATE
快速定位与兜底处理
即便做了预防，线上仍可能偶发死锁。Hyperf 配合 MySQL，可做到自动重试 + 日志可查。
- 捕获 PDOException 中的 SQLSTATE 40001（deadlock detected），在业务层做最多 2–3 次指数退避重试
- 开启 InnoDB 状态输出：SET GLOBAL innodb_status_output = ON，定期执行 SHOW ENGINE INNODB STATUS\G 查看 LATEST DETECTED DEADLOCK 区域
- 在 Hyperf 日志中记录事务开始/提交/回滚耗时，配合 trace_id 关联慢事务，辅助判断是否因某类操作长期持锁引发连锁反应
