Go语言如何处理数据库死锁问题_Golang重试策略与锁顺序规范-Golang-PHP中文网

Go中SQLite报“database is locked”错误的根源是未及时关闭*sql.Rows导致读锁滞留，正确做法是立即defer rows.Close()确保资源释放。

go语言如何处理数据库死锁问题_golang重试策略与锁顺序规范

Go 的 database/sql 本身不产生死锁，但事务未提交、rows 未关闭、SQL 执行顺序混乱，会触发 MySQL/SQLite 底层死锁（如错误码 1213）或 database is locked、invalid connection 等表现。修复关键不在“加锁控制连接”，而在管住三件事：事务生命周期、查询结果集释放、SQL 执行顺序。

如何识别并重试 MySQL Deadlock（错误码 1213）

MySQL InnoDB 主动检测到循环等待后会回滚一个事务，并返回明确错误：Deadlock found when trying to get lock，对应驱动错误码 1213。忽略它或静默重试整个业务流程，会导致数据不一致或雪崩。

必须显式判断错误类型：用 mysql.MySQLError 类型断言，或检查 err.Error() 是否包含 "1213"
重试仅限事务体内部逻辑，且最多 3 次；每次重试前加随机抖动：time.Sleep(time.Millisecond * time.Duration(rand.Intn(50)+50))
禁止在重试外层包裹 db.Query 或 db.Exec —— 这些操作不属事务，重试它们无意义，还可能重复写入
若事务内含 SELECT ... FOR UPDATE，确保所有同类语句都走同一索引路径，否则即使顺序一致也可能因执行计划不同引发新死锁

为什么 SQLite 报 database is locked？根源在 rows.Close() 没 defer

SQLite 是文件锁模型，*sql.Rows 不关闭 → 底层连接卡在读锁状态 → 写操作全部阻塞 → 表现为 database is locked。这不是并发高导致的，单 goroutine 忘关 rows 就立刻触发。

rows, err := db.Query() 后必须立刻写 defer rows.Close()，哪怕只查一行、甚至 err != nil
禁止把 rows.Close() 放进 if rows.Next() 块里，或放在 tx.Commit() 之后——panic 或提前 return 会让它被跳过
db.QueryRow() 内部仍可能打开隐式 rows；若 .Scan() 失败，错误可能来自未释放的资源（虽少见，但 Query 场景必须严守）
db.Close() 不会清理已发出但未 Close() 的 rows，它只回收空闲连接

UPDATE/DELETE 多行时如何避免 AB-BA 死锁？统一按主键升序执行

MySQL 死锁高频场景是多行更新顺序不一致：goroutine A 先更新 ID=100 再更新 ID=50，goroutine B 反过来，形成循环等待。InnoDB 锁的是索引记录，顺序错即死锁。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

所有涉及多 ID 的 UPDATE 或 DELETE，必须先对 ID 切片排序：sort.Slice(ids, func(i, j int) bool { return ids[i]
拼 SQL 时强制加 ORDER BY id（如 UPDATE users SET status=1 WHERE id IN (?, ?) ORDER BY id），防止优化器乱序
禁止在事务中调用 HTTP 请求、写文件、复杂计算——这些拉长锁持有时间，显著提高死锁概率
若业务需按业务字段（如 created_at）更新，应先 SELECT id FROM ... ORDER BY created_at LIMIT N 拿到有序 ID 列表，再用该列表做后续 UPDATE