Go SQL 事务遇到死锁怎样设计有限重试

Go 的 database/sql 没有替应用自动判断“这个错误是否值得重试”。比较稳妥的做法是把一次完整事务当成一个不可拆分的工作单元：从 BeginTx 开始，所有读取和写入都使用同一个 *sql.Tx，遇到数据库明确标识的死锁后回滚整个事务，等待一小段有上限的时间，再从头开始；普通业务错误、约束错误和未知的提交错误都直接返回。

官方入口：https://pkg.go.dev/database/sql。本文只讨论事务重试边界，不把“所有数据库错误都再试一次”当成方案。

先把可重试错误和业务错误分开

我在排查这类问题时，最先确认的不是重试次数，而是错误分类。死锁的本质是多个事务互相等待，数据库为了打破等待环会主动回滚其中一个事务；这和唯一键冲突、参数错误、权限不足不是一回事。后几类错误即使再执行，也不会因为等待一会儿就自然变好。

不同驱动暴露错误信息的方式不同，因此重试器不应该在通用层里用字符串包含“deadlock”来猜。MySQL InnoDB 常见的死锁错误是 1213；PostgreSQL 使用 SQLSTATE 40P01 表示 deadlock_detected，而 40001 表示 serialization_failure。这些编号要由当前驱动的错误类型适配，而不是硬编码成对所有数据库都成立的规则。

MySQL 官方建议，事务因死锁回滚后要重新发起整个事务，并尽量缩短事务、统一访问顺序。PostgreSQL 文档也强调，发生序列化失败时要从头重试包括决定执行哪些 SQL 和使用哪些值的完整事务逻辑。参考地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html、https://www.postgresql.org/docs/current/mvcc-serialization-failure-handling.html。

重试的最小边界是整个事务

死锁发生后，当前事务已经不再是可以安全继续使用的工作空间。只重发刚刚失败的那条 SQL，可能遗漏前面已经读取的值，也可能把一半旧状态和一半新状态拼在一起。正确的边界是“重新开始一次业务操作”，而不是“重新执行上一条语句”。

下面的包装器把错误判断函数作为参数传入。事务控制层只负责生命周期；MySQL、PostgreSQL 或其它驱动的错误码映射放在适配层，换数据库时不会把驱动细节散落在所有业务函数里。

package txretry

import (
    "context"
    "database/sql"
    "errors"
    "fmt"
    "time"
)

// RetryDecider 只应把已确认会回滚事务的瞬时错误判为可重试。
type RetryDecider func(error) bool

// Run 在一次尝试中完成整个业务事务，失败后才重新 BeginTx。
func Run(ctx context.Context, db *sql.DB, maxAttempts int, isRetryable RetryDecider, work func(context.Context, *sql.Tx) error) error {
    if maxAttempts 

这个例子有意把 work 放在循环内部。它必须重新读取本次事务需要的状态，重新计算要写入的值，不能把上一轮的 *sql.Tx、行锁对象或依赖旧快照的结果带进下一轮。

退避要有限，也要能被取消

重试不是越快越好。多个请求同时遇到死锁时，如果所有请求立即再次抢锁，可能形成新一轮碰撞。短暂退避可以给另一方事务释放锁的机会，但退避必须有三个出口：尝试次数有上限，单次等待有上限，请求的 context 取消时立即退出。

示例用平方增长的 25 毫秒作为简单退避：第 2 次前等待 25 毫秒，第 3 次前等待 100 毫秒，第 4 次前等待 225 毫秒。生产环境可以加入受控抖动，但要保留最大等待值，并把实际尝试次数、数据库错误码和总耗时记录到指标或日志中。不要把退避写成固定的无限 for，也不要在没有检查 ctx.Done() 的情况下直接 time.Sleep。

maxAttempts 不是“保证成功”的承诺。如果三次尝试都遇到明确死锁，最终仍应把错误交给上层，由上层决定返回冲突、排队、降级或触发人工处理。有限重试的价值是吸收偶发并发碰撞，而不是掩盖持续存在的锁顺序问题。

统一加锁顺序，别只依赖重试

我更愿意把重试看成最后一道缓冲，而不是死锁修复本身。两个事务如果一个先锁“账户行”再锁“库存行”，另一个先锁“库存行”再锁“账户行”，就可能形成等待环。把所有相关业务路径约束为相同顺序，通常比把重试次数从 3 次改成 30 次更有效。

锁顺序应该落到代码结构里，而不是只写在文档里。例如转账和库存扣减都涉及账户与库存时，可以让两类操作先按稳定的主键顺序锁账户，再锁库存；涉及多行同类资源时，先排序 ID 后按同一方向访问。索引是否能缩小扫描范围、事务是否夹带慢查询和外部调用，也会影响锁持有时间。

错误适配器只认明确证据

通用重试函数需要的不是“看起来像临时错误”，而是一个可审查的适配器。适配器可以按当前数据库驱动的原生错误类型读取错误码：例如 MySQL 驱动的错误号 1213，或者 PostgreSQL 驱动错误的 SQLSTATE 40P01；是否把 40001 一并重试，则要结合应用的隔离级别和业务语义。

不要用错误字符串模糊匹配，也不要把所有连接错误、超时、唯一键冲突都塞进 isRetryable。特别是 Commit 阶段的网络断开，客户端可能不知道数据库究竟提交成功还是没有提交；这种“结果未知”不能按普通死锁回滚来处理。需要重试时，应先有幂等键、状态查询或业务补偿方案。

// 这是适配层的职责示意；具体类型按项目使用的驱动实现。
func retryableDatabaseError(err error) bool {
    // 例如：MySQL 只认 1213；PostgreSQL 可认 40P01，必要时再单独评估 40001。
    // 未匹配到明确错误码时返回 false，避免把业务失败变成重复写入。
    code := databaseErrorCode(err)
    return code == "1213" || code == "40P01"
}

// databaseErrorCode 应由项目的 MySQL/PostgreSQL 驱动适配器提供。
func databaseErrorCode(error) string {
    return ""
}

上面的 databaseErrorCode 是接口边界示意，不是可以直接替代驱动适配的实现。这样写的好处是：错误码清单可以独立评审，事务包装器也不会因为更换驱动而改动。

把幂等和外部副作用放在重试边界之外

数据库事务回滚只能撤销数据库里的变化，不能撤销已经发送的邮件、扣款请求、消息投递或第三方 HTTP 调用。若 work 在事务中途触发了外部副作用，随后因死锁重试，就可能重复执行外部动作。

更稳妥的做法是让事务只写入可回滚的业务状态和待发送事件，提交成功后再由可靠的 outbox 消费者执行外部动作；或者为外部操作设计幂等键，让重复请求得到同一个业务结果。重试器本身只应包围可安全重新计算的数据库工作单元。

还要区分“读到旧值后再次写入”和“重新计算业务决策”。下一次事务必须重新读取需要锁定的数据，不能把上一轮的查询结果当成新一轮事实。对于库存、余额、配额这类数值，最好让 SQL 条件和受影响行数共同参与判断，而不是在 Go 内存里拿旧值盲写。

我会用这张清单决定是否重试

如果只能记住一句话，就是：死锁重试的最小单位是完整事务，判断依据是明确错误码，次数和退避必须有上限，提交结果不确定时不能装作已经回滚。把这四点固定在代码边界里，重试才是可控的容错，而不是重复写入的放大器。

为什么不能只重试失败的 SQL？

因为死锁通常意味着数据库已经回滚了当前事务，而后续 SQL 依赖的读取快照、锁和中间状态都已失效。只重试一条语句会破坏原本的业务原子性。

锁等待超时也应该按死锁重试吗？

不能直接等同。锁等待超时在不同数据库和配置下可能只回滚当前语句，也可能回滚整个事务。必须查清当前引擎的语义，确认事务状态和业务可重复性后再决定。

重试次数设置多少合适？

没有通用数字。先根据请求超时、事务平均耗时和并发冲突情况设一个很小的上限，再用指标观察；如果经常耗尽上限，应优先处理锁顺序、索引和事务范围。