tp5.1项目死锁源于repeatable read下的间隙锁与长事务，应切换为read committed隔离级别、压缩事务边界、移除非db操作、拆分事务、设置锁等待超时并实现死锁自动重试。
TP5.1项目中频繁报错“Deadlock found when trying to get lock”，接口偶发失败、订单状态不一致、库存扣减丢失，根本原因是InnoDB在REPEATABLE READ隔离级别下触发间隙锁+事务执行时间过长，导致多个并发请求互相等待同一组索引资源。
确认当前隔离级别并切换为READ COMMITTED
进入MySQL命令行，执行：SELECT @@transaction_isolation; → 查看返回值是否为REPEATABLE-READ。
若确认是REPEATABLE READ，立即在TP5.1数据库配置文件config/database.php中修改：'params' => ['charset' => 'utf8mb4', 'options' => [\PDO::ATTR_CASE => \PDO::CASE_NATURAL, \PDO::MYSQL_ATTR_INIT_COMMAND => "SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED"]]。
【必须重启PHP-FPM或Web服务器进程，否则新隔离级别不会生效】
READ COMMITTED能消除间隙锁（Gap Lock），大幅降低因范围查询引发的死锁概率——比如WHERE status = 0 AND created_at > '2026-07-01'这类条件不再锁定索引间隙。
定位并压缩事务边界
第一步：打开TP5.1的SQL日志，在config/database.php中设置'debug' => true，复现一次死锁请求，从runtime/log下找到对应SQL执行序列。
第二步：检查事务块内是否混入非DB操作——例如调用第三方HTTP接口、生成PDF、写本地文件、复杂循环计算。这些操作必须全部移出Db::transaction()包裹范围。
第三步：将原本一个事务内完成的“查库存→扣减→写日志→发MQ”拆成两个独立事务：前两步为一个短事务（
这一步不做，哪怕隔离级别调低，只要事务内含sleep(1)或file_get_contents()，锁就一直挂着，死锁概率不降反升。
强制统一SQL访问顺序（方法一：代码层硬约束）
方法一：在模型类中定义静态锁序规则。例如订单与库存关联场景，所有涉及order和stock表的操作，必须严格按order → stock顺序执行UPDATE。
方法二：对共用资源加应用层分布式锁。使用Redis SETNX指令，在事务开始前获取lock:order_stock_sync，超时设为3秒，未获取到则直接返回重试提示，避免进入数据库锁竞争。
方法三：改写SQL，用单条语句替代多步更新。例如原逻辑UPDATE stock SET num = num - 1 WHERE id = 123; UPDATE order SET status = 2 WHERE id = 456;，合并为UPDATE stock s JOIN order o ON s.goods_id = o.goods_id SET s.num = s.num - 1, o.status = 2 WHERE s.id = 123 AND o.id = 456;——单语句只持有一把锁，彻底规避交叉等待。
【TP5.1默认不支持跨表JOIN更新，此方法需手动使用Db::execute()执行原生SQL】
设置锁等待超时并启用自动重试
在config/database.php的params数组中追加：\PDO::MYSQL_ATTR_INIT_COMMAND => "SET SESSION innodb_lock_wait_timeout = 10"，将锁等待上限从默认50秒压至10秒。
在业务逻辑中捕获异常：try { Db::transaction(function () { ... }); } catch (\PDOException $e) { if ($e->getCode() == '40001' || strpos($e->getMessage(), 'Deadlock') !== false) { usleep(rand(10000, 50000)); // 随机延迟10~50ms retry(); } }。
这一步必须做——InnoDB检测到死锁后会回滚事务并抛出错误码40001，不重试等于主动放弃请求。
