需开启innodb_print_all_deadlocks=ON并确保log_error可写，死锁日志仅存于错误日志；Go中需捕获*mysql.MySQLError且Number==1213识别真死锁，避免非确定顺序加锁，结合时间戳、SQL模式与事务日志交叉定位。
查不到死锁日志？先确认 MySQL 是否开了死锁检测和日志输出
MySQL 默认不会把死锁信息写进错误日志，除非显式开启 innodb_print_all_deadlocks。不打开它，SHOW ENGINE INNODB STATUS 只保留最后一次死锁，线上出问题根本来不及抓。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 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 时更难分辨。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 捕获
*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语言免费学习笔记（深入）”；
- 在 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。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 安装后直接运行：
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 都是盲人摸象。
