QueryContext 无法真正中断服务端 SQL 执行，因 Go 的 database/sql 仅封装驱动，实际中断依赖驱动实现与数据库服务端配合；PostgreSQL（pgx）支持异步取消，MySQL 仅限未返回结果前，SQLite 不支持服务端中断。
为什么 database/sql 的 QueryContext 不能直接中断正在执行的 SQL？
很多人以为只要传入带超时的 context.Context 给 QueryContext，数据库就会“立刻中止”正在跑的查询。事实并非如此：PostgreSQL、MySQL 等多数驱动只在「建立连接」「读取结果行」「等待服务器响应」等 I/O 阶段响应 cancel；如果 SQL 已在服务端长时间运行（比如全表扫描、复杂 JOIN），客户端发 cancel 信号后，仍需等服务端主动检查并终止——这中间可能有数秒甚至更久延迟。
根本原因在于：Go 的 database/sql 层不控制服务端执行逻辑，它只是对底层驱动的封装；是否支持真正中断，取决于驱动实现 + 数据库服务端配合。
- PostgreSQL 驱动（
lib/pq或jackc/pgx）支持发送 CancelRequest，但依赖服务端定期检查 cancellation（默认每 100ms 一次） - MySQL 驱动（
go-sql-driver/mysql）在 v1.7+ 后支持context.CancelFunc中断，但仅限于未返回结果前；一旦开始返回 rows，cancel 会阻塞直到全部读完或网络断开 - SQLite 驱动（
mattn/go-sqlite3）不支持服务端中断，cancel 只能中断 Go 协程读取，SQL 仍在 SQLite 内部执行
用 pgx 实现真正可中断的 PostgreSQL 查询
pgx 是目前对上下文取消支持最完善的 PostgreSQL 驱动，它在底层使用异步取消协议，并暴露了 Conn.CancelRequest() 的显式调用能力。关键不是只靠 QueryContext，而是结合连接复用与手动 cancel。
实操要点：
- 不要从
*pgxpool.Pool直接调用QueryContext—— pool 返回的 conn 是共享的，无法单独 cancel - 改用
pool.Acquire(ctx)获取独占连接，再调用conn.Query(ctx, ...) - 若需提前中断，调用
conn.CancelRequest()（无需等待响应，它只是发一个异步包） - 务必在 defer 中调用
conn.Release()，否则连接不会归还池中
示例片段：
conn, err := pool.Acquire(ctx)
if err != nil {
return err
}
defer conn.Release()
// 启动查询，ctx 控制整个生命周期
rows, err := conn.Query(ctx, "SELECT pg_sleep(30)")
if err != nil {
// ctx 被 cancel 时，这里会返回 context.Canceled 或 context.DeadlineExceeded
return err
}
defer rows.Close()
// 正常处理 rows...
MySQL 场景下如何降低 cancel 延迟？
MySQL 驱动虽支持 QueryContext，但常见问题是：cancel 触发后，rows.Next() 仍卡住，直到所有结果被读完。这是因为 MySQL 协议要求客户端必须消费完全部结果集才能释放连接。
解决路径只有两个方向：
- 在 SQL 层加限制：强制用
LIMIT，或拆分大查询为多次小查询（例如分页 + offset，或按时间范围切片） - 启用
interpolateParams=true（仅开发/测试）避免预编译带来的额外延迟，但生产慎用 - 升级到
go-sql-driver/mysql v1.7+并确保 DSN 中包含timeout=5s&readTimeout=5s&writeTimeout=5s，让底层 net.Conn 更快响应 cancel - 避免使用
db.QueryRowContext执行可能长时间运行的语句——它内部会调用rows.Close()，而该操作可能阻塞
真正高风险查询建议改用 ExecContext + SELECT ... INTO OUTFILE 或物化临时表，把耗时逻辑移出 Go 进程。
别忽略连接池和上下文的生命周期耦合
一个容易被忽略的坑是：把短生命周期的 context.WithTimeout 传给长期复用的连接池方法（如 pool.QueryRow）。这时即使 ctx 超时，pool 内部可能已将请求派发到某个 conn，而该 conn 正在阻塞读取——你 cancel 的只是当前 goroutine，不是那个正在 I/O 的 conn。
所以正确做法是：
- 对每个需要中断的查询，都用新 acquire 的连接，而不是复用池的便捷方法
- 永远不要在
context.Background()上调用WithCancel后忘记调用 cancel 函数，否则 goroutine 泄漏 - 如果业务允许，用
pool.Config.MaxConns = 1搭配单次 acquire，彻底规避连接复用干扰（适合低并发、高确定性场景）
中断不是加个 context 就能生效的魔法，它是客户端、驱动、协议、服务端四层协作的结果；其中任意一层掉链子，你的 ctx.Done() 就只是个安静的信号。
