如何在ThinkPHP数据库操作中捕获死锁异常_特定PDO重试机制解析-ThinkPHP-PHP中文网

thinkphp中mysql死锁抛出错误码1213的pdoexception，需用$e->getcode() === '1213'精确判断，配合pdo::errmode_exception配置、显式事务及连接重建的指数退避重试机制。

如何在thinkphp数据库操作中捕获死锁异常_特定pdo重试机制解析

死锁异常在ThinkPHP里到底长什么样

ThinkPHP 6.x 默认用 PDO 连接 MySQL，死锁触发时抛出的不是 PDOException 的泛型错误，而是具体错误码为 1213 的异常，消息里带 Deadlock found when trying to get lock。你如果只 catch Throwable 却没检查错误码，重试逻辑就完全失效。

常见错误现象：事务中执行 update 或 select for update 突然报错，但日志里只显示“SQLSTATE[40001]: Serialization failure”，这是误判——MySQL 死锁是 40001 吗？不是，那是序列化失败；死锁固定是 HY000 + 1213。

务必用 $e->getCode() === '1213' 判断，别信 SQLSTATE
ThinkPHP 的 Db::transaction() 不会自动捕获或重试，得自己包一层
注意 PDO 的 ATTR_ERRMODE 必须设为 PDO::ERRMODE_EXCEPTION，否则死锁直接静默失败

手动实现带重试的事务函数（非装饰器）

别依赖第三方重试库，ThinkPHP 场景下最稳的是写个带指数退避的裸循环。关键不是“重试几次”，而是“每次重试前必须释放当前 PDO 连接并重建事务上下文”——否则第二次 beginTransaction() 会失败。

使用场景：库存扣减、订单状态互斥更新、积分流水对账等强一致性写操作。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

重试前调用 $connection->close()，再通过 Db::connect() 拿新连接
最大重试次数建议 ≤ 3，超过说明业务逻辑本身有锁竞争设计缺陷
退避时间从 50ms 起步，每次 ×1.5（比如 50 → 75 → 112），避免雪崩式重试

示例核心逻辑：

for ($i = 0; $i getCode() !== '1213') throw $e;
        if ($i === 2) throw $e;
        usleep((int)(50 * pow(1.5, $i) * 1000));
    }
}

PDO 配置项对死锁感知的影响

ThinkPHP 的数据库配置里，params 字段直接透传给 PDO 构造函数。几个关键项不设对，死锁根本捕不到或重试无效。

PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION 是前提，缺了就 catch 不到
PDO::ATTR_TIMEOUT => 3 建议显式设为 3 秒，防止锁等待卡死整个请求
PDO::MYSQL_ATTR_INIT_COMMAND => "SET innodb_lock_wait_timeout = 3" 要配，否则 MySQL 默认锁等待 50 秒，重试毫无意义
别开 PDO::ATTR_PERSISTENT，持久连接会让事务状态跨请求污染，死锁重试时极易复现“Cannot execute queries while other unbuffered queries are active”

为什么不能在模型 save() 里直接套重试

save() 内部调用的是 insert() 或 update()，它们默认不开启事务，也不暴露底层 PDO 实例。你 wrap 一个 save() 并 catch 死锁，大概率 catch 不到——因为真正触发死锁的可能是它内部的关联查询或事件回调里的额外 SQL。

容易踩的坑：

在 afterSave 钩子里做 Db::table()->where()->update()，这个 update 才是死锁源，但外层 save() 的 try/catch 完全不覆盖它
用 Model::update() 静态方法时，它走的是非事务批量更新，根本不会报死锁（而是直接阻塞超时）
正确做法：把所有可能冲突的操作收拢到一个显式 Db::transaction() 块里，而不是分散在模型生命周期钩子中

复杂点在于，死锁不是纯技术问题，它暴露的是行锁粒度和执行顺序的设计盲区。重试只是兜底，真要稳定，得看 SQL 是否命中索引、where 条件是否导致锁升级、事务里有没有混合读写顺序颠倒——这些比写重试逻辑难得多。