不能直接中断sql查询，但能防止goroutine泄漏；新版本mysql/postgresql驱动支持发送kill query或cancelrequest，旧版或不支持cancel的数据库仅放弃等待而查询仍在服务端运行。
Go 的 context.WithTimeout 能否中断正在执行的 SQL 查询？
不能直接中断——但能防止 goroutine 泄漏和后续操作继续等待。MySQL/PostgreSQL 驱动（如 github.com/go-sql-driver/mysql 或 github.com/lib/pq）在收到 context.Context 取消信号后，会尝试向数据库发送取消请求（如 MySQL 的 KILL QUERY），前提是驱动版本较新且数据库支持。老版本驱动或不支持 cancel 的数据库（如某些 SQLite 封装）只会放弃等待，而查询仍在服务端运行。
实操建议：
- 确认驱动版本：MySQL 驱动需 ≥ v1.7.0；PostgreSQL 驱动需 ≥ v1.10.0 才真正支持 context cancel
- 连接字符串中显式启用 cancel 支持：
?timeout=30s&readTimeout=30s&writeTimeout=30s（MySQL）或connect_timeout=30（PostgreSQL）仅控制建连阶段，不影响 query 执行期超时 - 永远用
db.QueryContext/db.ExecContext替代Query/Exec，否则 context 完全无效
sql.DB.SetConnMaxLifetime 和 context.WithTimeout 解决的是不同层面的问题
前者管连接池里单个连接“活多久”，后者管某次具体 SQL 操作“最多等多久”。混淆这两者是常见错误源头。
典型误用现象：设置了 SetConnMaxLifetime(5 * time.Second)，却期望它能让慢查询在 5 秒后自动终止——结果只是连接被回收，而查询还在 DB 里跑着，甚至可能因重连重试导致雪崩。
正确分工：
-
SetConnMaxLifetime：防连接老化（如数据库主动断连、防火墙踢空闲连接），设为略小于 DB 的wait_timeout -
SetConnMaxIdleTime：控制空闲连接存活时间，避免积压无效连接 -
context.WithTimeout：绑定到每次QueryContext调用，精确控制该次 SQL 的最大等待+执行耗时
超时后调用 rows.Close() 为什么还 panic: "sql: Rows are closed"？
因为 context 超时触发 cancel 后，rows 可能已由驱动内部提前关闭，此时再手动 rows.Close() 就会 panic。这不是 bug，而是并发安全设计：驱动在 cancel 时已接管资源清理。
安全写法：
- 总是用
defer rows.Close()，哪怕用了 context —— Go 的defer在 panic 时仍会执行，且Close()对已关闭的Rows是幂等的（新版 sql 驱动已修复该 panic，但旧版仍存在） - 检查
err是否为context.DeadlineExceeded或context.Canceled，而不是依赖rows.Err()判断超时 - 避免在
for rows.Next()循环中嵌套耗时操作，否则超时可能发生在循环中途，rows.Close()无法释放底层连接
PostgreSQL 中 pgx 比 database/sql + lib/pq 更可靠地支持 query cancel
pgx 原生实现协议级 cancel（通过发送 CancelRequest 消息），响应更快、成功率更高；而 lib/pq 在 database/sql 框架下需绕一层，cancel 有时会延迟数秒甚至失败。
如果你用 PostgreSQL 且对超时精度要求高：
- 直接上
pgx/v5，用conn.Query(ctx, sql, args...) - 避免混用
pgxpool.Pool和database/sql接口——虽然兼容，但 cancel 行为退化为lib/pq级别 -
pgx的ctx超时包含网络往返，实际 DB 执行时间可能略短于设定值，需留 100–200ms 余量
context 超时不是万能开关，它依赖驱动、协议、数据库三者协同。最容易被忽略的一点：即使 cancel 成功，你也得自己处理好业务状态——比如订单创建超时后，不能假设 DB 一定没插入，必须加幂等键或查证结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
