Go中SQLite报“database is locked”错误的根源是未及时关闭*sql.Rows导致读锁滞留，正确做法是立即defer rows.Close()确保资源释放。
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 锁的是索引记录，顺序错即死锁。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
立即学习“go语言免费学习笔记（深入）”；
- 所有涉及多 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
invalid connection 报错不是 Go 的问题，而是死锁后的连接残留失效
invalid connection 通常不是客户端主动断开，而是 MySQL 在事务因死锁被回滚后，又遭遇 wait_timeout 触发、网络超时，或客户端后续读包时连接已由服务端关闭，最终在 readPacket() 阶段报错。
- 这个错误是“果”不是“因”——先有死锁，才有连接异常；只修
invalid connection不解决根本 - 不要靠
db.SetConnMaxLifetime()缓解：它只影响空闲连接，对已卡在死锁中的活跃连接无效 - 启用
db.SetMaxOpenConns(0)（不限制）反而更危险：更多并发事务加剧锁竞争 - 真正有效的防御是前置控制：用
context.WithTimeout()包裹事务，确保单次执行不超 3 秒；超时自动 rollback，避免锁长期占用
最易被忽略的一点：死锁修复不是加锁粒度越细越好。过度拆分事务、频繁 commit，可能让业务逻辑割裂、数据中间态暴露。重点始终是让 SQL 执行可预测——顺序固定、资源释放及时、外部依赖剥离。否则，再精细的锁策略也挡不住执行路径本身的不确定性。
