ThinkPHP6应对一万并发数据库死锁的关键是捕获错误码1213后指数退避重试、统一多表操作顺序（如user→order→item→log）、缩小事务粒度并移出HTTP/Redis等耗时操作、优化索引避免间隙锁冲突。
ThinkPHP6 在应对一万并发时出现数据库死锁，不是框架本身缺陷，而是高并发下事务资源竞争的自然结果。关键不在于“彻底消灭死锁”，而在于让系统能快速识别、安全重试、并从设计上大幅降低发生概率。以下方法已在真实电商、支付类线上场景验证有效。
捕获死锁并自动重试（必须做）
TP6 默认不会自动处理死锁异常，需手动包裹事务并检查错误码 1213。
- 开启 PDO 异常模式：确保数据库配置中 'options' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] 已启用
- 重试逻辑必须在 try-catch 内重新 beginTransaction()，不能复用已中断事务
- 建议最多重试 3 次，第 1 次延迟 50ms，第 2 次 100ms，第 3 次 200ms（指数退避），避免集群内二次碰撞
- 不要在重试中 sleep(100)，固定等待会加剧排队雪崩
统一 SQL 执行顺序（最有效预防）
死锁约 70% 来源于不同接口对相同表的加锁顺序不一致。例如订单创建和库存扣减，若一个先更新 order 再更新 stock，另一个反着来，极易成环。
- 在项目文档或 base service 中明确定义「全局操作顺序」，如：user → order → item → log
- 所有涉及多表变更的事务（包括模型 save()、Db::transaction()、Query Builder 链式调用），严格按此顺序组织 SQL
- TP6 的
Db::transaction()回调内，禁止动态拼接表名或条件导致执行路径不可控
缩小事务粒度 + 移出耗时操作
TP6 应用常见陷阱：在 Db::transaction() 里调用微信支付回调、写本地日志、触发 Redis 缓存更新——这些不涉及数据库一致性保障的操作，必须移出事务。
- 只把真正需要原子性的 DB 写操作留在事务内（如扣库存 + 改订单状态）
- HTTP 请求、文件写入、Redis set、消息推送等全部放在
$transaction->commit()之后 - 使用 TP6 的
afterCommit()钩子（需自行封装或借助事件监听）做后续异步动作
索引与语句优化（防间隙锁死锁）
InnoDB 在可重复读级别下，UPDATE ... WHERE name LIKE 'xxx%' 或 WHERE id > 100 AND id 可能触发间隙锁冲突，两个事务互锁间隙，形成死锁。
- 所有
FOR UPDATE和UPDATE/DELETE必须走唯一索引或主键，避免范围扫描 - 检查慢查询日志中是否出现未命中索引的更新语句，用
EXPLAIN验证执行计划 - 对高频并发更新字段（如库存
stock），考虑添加覆盖索引或改用乐观锁（version 字段 + CAS 更新）
不复杂但容易忽略：死锁不是故障，是并发系统的常态信号。TP6 本身轻量且可控，真正决定稳定性的，是你对事务边界的敬畏、对锁行为的理解，以及对重试逻辑的严谨实现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
