应优先用 sqlstate == '40001' 判断 MySQL 死锁，而非 errno 或错误消息；重试须包裹整个事务块，避免业务不一致，并需结合索引优化与访问顺序统一来根治高频死锁。
捕获 MySQL Deadlock 错误码 1213
MySQL 在发生死锁时会主动回滚其中一个事务，并抛出 ERROR 1213 (40001): Deadlock found when trying to get lock。关键不是“有没有报错”，而是你的代码是否真正识别了这个错误——很多 ORM 或封装层会把错误信息吞掉、转成通用异常，导致你看到的只是 OperationalError 或 DatabaseError，而没检查 errno 或 sqlstate。
实操建议：
- 直接检查异常对象的
args、errno（PyMySQL/MySQLdb）或orig.args[0]（SQLAlchemy 的底层驱动异常）是否等于1213 - 优先用
sqlstate == '40001'判断，它比 errno 更标准（ANSI SQL 定义），且不受 MySQL 版本或驱动实现差异影响 - 避免只靠错误消息字符串匹配（如
"Deadlock"），容易因语言/版本/日志截断失效
重试逻辑必须包裹整个事务块，而非单条语句
死锁发生在事务执行过程中多个锁竞争时，单独重试某条 UPDATE 或 INSERT 没有意义——事务上下文已丢失，再执行可能违反业务一致性（比如前一步已发通知、改了缓存，但数据库回滚了）。
实操建议：
- 把「开启事务 → 执行业务 SQL → 提交」整个流程放在一个可重试的函数内，例如 Python 中用
while retry_count 包裹 <code>connection.begin()到connection.commit() - 每次重试前必须重新获取连接（或确保连接未关闭），不能复用上一次失败的连接对象
- 在重试前加随机退避（如
time.sleep(random.uniform(0.01, 0.1))），避免多个客户端同步重试造成二次死锁
哪些操作不适合自动重试
不是所有报 1213 的场景都该无脑重试。盲目重试可能掩盖设计问题，甚至引发副作用。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
以下情况应记录告警并人工介入，而非重试：
- 事务中包含非幂等的外部调用（如 HTTP 请求、发邮件、扣第三方账户余额）
- 业务逻辑依赖 SELECT 结果做判断（如“余额 > 100 才扣款”），而重试时数据已被其他事务修改，导致重复扣款或漏扣
- 事务持续时间过长（> 1s），说明存在锁持有时间不合理，应先优化 SQL 或索引，而不是靠重试掩盖
- 高频死锁（> 1% 的事务失败率），大概率是表结构、索引缺失或访问顺序不一致，需用
SHOW ENGINE INNODB STATUS查死锁详情
Go / Python / Java 的典型重试写法差异
不同语言生态对事务控制粒度不同，重试实现细节容易出错。
Python（使用 pymysql）示例片段：
for i in range(3):
try:
conn = get_db_conn()
with conn.cursor() as cur:
cur.execute("START TRANSACTION")
cur.execute("UPDATE accounts SET balance = balance - 10 WHERE id = %s", [uid])
cur.execute("INSERT INTO logs (...) VALUES (...)")
conn.commit()
break
except pymysql.MySQLError as e:
if e.sqlstate == '40001' and i < 2:
time.sleep(0.05 * (2 ** i)) # 指数退避
continue
raiseGo（使用 database/sql）要注意：事务对象 *sql.Tx 失败后不可复用，必须 tx.Rollback() 后新建；Java（JDBC）同理，Connection.createStatement() 必须在 tx 对象内创建，不能跨事务复用 Statement。
最容易被忽略的一点：重试次数上限必须设（通常 2–3 次），且最后一次失败必须抛出原始异常，否则上层无法区分是业务失败还是死锁重试耗尽。
