应优先检查exc.sqlstate == '40001'识别MySQL死锁，因其跨驱动和版本稳定；重试必须包裹整个事务并调用rollback()，配合指数退避与次数限制（如3次），避免盲目重试掩盖架构问题。
怎么准确识别MySQL死锁错误
不能靠字符串匹配"Deadlock"，也不能只抓Exception大类——很多ORM（比如SQLAlchemy或Django）会把原生错误包装掉，exc.args[0]可能不是1213，exc.sqlstate才最稳。
实操建议：
- 优先检查
exc.sqlstate == '40001'，这是ANSI SQL标准定义的死锁状态码，跨驱动、跨MySQL版本都可靠 - PyMySQL/MySQLdb下可退而求其次看
exc.args[0] == 1213，但注意exc.args结构因驱动版本略有差异 - Spring JDBC里必须用
SQLException.getSQLState().equals("40001")，getErrorCode()在MySQL Connector/J 8.0+某些配置下不返回1213 - 绝对不要用
"Deadlock found" in str(exc)——日志被截断、多语言环境、中间件改写消息都会让它失效
重试必须包裹整个事务，而不是单条SQL
死锁发生在事务内部多个锁竞争时，单独重试某条UPDATE或INSERT毫无意义：事务上下文已丢失，再执行可能造成业务逻辑错乱（比如缓存已更新但DB回滚了）。
实操建议：
- 把
begin→业务SQL→commit整个流程放进一个可重试函数，每次重试都开新事务 - 重试前必须调用
conn.rollback()（如果连接还活着），否则下次execute会报Commands out of sync - 每次重试都要重新获取连接句柄，别复用失败事务里的
connection对象——它可能处于不可用状态 - Java里别直接给Service方法加
@Transactional和@Retryable，Spring的事务上下文不会随重试刷新，容易导致二次执行时数据已变
退避策略和次数限制不能省略
裸while True重试是灾难：所有客户端在同一毫秒重试，锁竞争更激烈，反而放大死锁概率。
实操建议：
- 用指数退避，例如Python里
time.sleep(0.01 * (1.5 ** attempt))，从10ms起步，第三次重试延迟约22.5ms - 硬性限定最大重试次数，3次足够——第3次还失败，大概率是设计问题（比如加锁顺序不一致），该告警而非继续压
- 并发请求多时，连接池最大连接数要预留余量：
max_pool_size ≥ 并发数 × 重试上限，否则Too many connections会掩盖真实死锁 - 重试间隙里连接空闲超时要设合理值（如
idleTimeoutMillis=60000），避免大量连接挂起不释放
哪些场景不该自动重试
不是所有1213都适合重试。盲目重试可能把架构缺陷包装成“暂时抖动”，甚至引发副作用。
实操建议：
- 事务里调用了外部HTTP服务或依赖用户输入——重试会导致重复通知、重复扣款等严重问题
- 前置条件已失效，比如库存扣减前查到有100件，重试时可能只剩1件，再扣就超卖
- 死锁高频发生（每分钟多次），说明加锁顺序不统一或索引缺失，该优先优化SQL和事务结构，而非堆重试逻辑
- 用
SELECT ... FOR UPDATE但WHERE条件没走索引，导致锁范围过大——重试只是延缓问题，不解决根本
重试本身很简单，难的是判断“这次到底该不该重试”——它不是兜底方案，而是给短暂资源竞争留的窄窗口。真正稳定的系统，80%的死锁靠统一加锁顺序和索引优化消灭，剩下20%才交给重试兜住。
