Golang排查MySQL死锁，日志分析详解

本文深入解析了在Go语言项目中高效排查MySQL死锁的完整方法论：从MySQL侧必须开启`innodb_print_all_deadlocks=ON`并确保错误日志可写，到Go应用层精准识别被包装成超时或连接异常的真实死锁（通过捕获`*mysql.MySQLError`并校验错误码1213），再到规避常见诱因（如非确定顺序加锁、滥用二级索引更新），最后通过时间戳+SQL模式+事务日志交叉比对定位争用代码，并推荐`pt-deadlock-logger`和OpenTelemetry等工具实现自动化、可观测的死锁根因分析——帮你跳出“日志找不到、错误判不准、现场抓不住”的排查困境，真正从并发逻辑层面终结死锁难题。

查不到死锁日志？先确认 MySQL 是否开了死锁检测和日志输出

MySQL 默认不会把死锁信息写进错误日志，除非显式开启 innodb_print_all_deadlocks。不打开它，SHOW ENGINE INNODB STATUS 只保留最后一次死锁，线上出问题根本来不及抓。

实操建议：

• 在 MySQL 配置文件（如 /etc/my.cnf）的 [mysqld] 段落加一行：innodb_print_all_deadlocks = ON，然后重启或动态设置：SET GLOBAL innodb_print_all_deadlocks = ON
• 确保 log_error 指向可读写的文件路径，且 MySQL 进程有写权限；否则即使开了，日志也静默丢失
• 死锁日志只记录在错误日志里，不是慢查询日志，也不是 general log —— 别翻错地方

Go 应用报 driver: bad connection 或 context deadline exceeded，其实是死锁被回滚了

Go 的 database/sql 驱动不会把死锁错误原样透传。MySQL 在检测到死锁后会选一个事务回滚，并返回 ERROR 1213 (40001): Deadlock found when trying to get lock，但 Go 层常被包装成连接异常或超时，尤其用了 context.WithTimeout 时更难分辨。

实操建议：

• 捕获 *mysql.MySQLError（需导入 github.com/go-sql-driver/mysql），检查 Number 字段是否为 1213：

  if err != nil {
      if mysqlErr, ok := err.(*mysql.MySQLError); ok && mysqlErr.Number == 1213 {
          // 真正的死锁
      }
  }

• 避免在事务里混用 SELECT ... FOR UPDATE 和非确定顺序的 WHERE 条件（比如用 IN 传无序 ID 列表），这是 Go 服务中最常见的死锁诱因
• 所有写操作尽量走主键更新，少用二级索引上的 UPDATE ... WHERE non_pk_col = ?，InnoDB 加锁范围难预测

从 MySQL 错误日志里定位 Go 请求对应的死锁现场

死锁日志本身不含应用层 traceID 或 goroutine ID，但可以通过时间戳 + SQL 模式 + 事务持续时间交叉比对。关键不是“找到那一行”，而是确认哪两个 Go 协程/HTTP 请求在争同一组资源。

实操建议：

• 在 Go 日志中打印事务开始时间、SQL 语句（脱敏）、以及执行耗时，例如：INFO db tx=0xabc123 start=2024-05-20T14:22:31.882Z sql="UPDATE accounts SET balance = ? WHERE id = ?"
• 死锁日志里关注 *** (1) TRANSACTION: 和 *** (2) TRANSACTION: 下的 mysql tables in use、locked tables、以及每条 SQL 的 lock_mode X locks rec but not gap 等描述，确认是否锁的是同一张表+同一行
• 注意：Go 中用 db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelRepeatableRead}) 不会改变死锁概率，InnoDB 死锁与隔离级别无关，只与加锁顺序有关

用 pt-deadlock-logger 自动捞日志比人肉 grep 更可靠

MySQL 错误日志滚动快、格式松散，靠 grep -A 20 "Deadlock" 容易漏掉上下文。而 pt-deadlock-logger（Percona Toolkit）能持续监听、解析、结构化输出，还能对接 Prometheus 或发 Slack。

实操建议：

• 安装后直接运行：pt-deadlock-logger --daemonize --log=/var/log/deadlocks.log /var/log/mysql/error.log，它会自动轮转并提取事务堆栈
• 配合 Go 的 pprof 或 OpenTelemetry，在死锁高频时段采集 goroutine profile，看是不是某类请求总在固定位置启动事务（比如某个 HTTP handler 总是先查再更，且并发高）
• 别依赖 SHOW PROCESSLIST 抓活锁——死锁是瞬态事件，等你连上去，现场早没了

死锁排查最耗神的地方不在工具链，而在确认「哪两段 Go 代码实际在抢同一行」。日志、SQL 模式、事务粒度、甚至 ORM 生成的 WHERE 顺序，都得串起来看。单看 MySQL 日志或单看 Go panic 都是盲人摸象。

本篇关于《Golang排查MySQL死锁，日志分析详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！