加context.WithTimeout不能解决慢SQL拖垮服务的问题，因为中间件只控制HTTP请求生命周期，而DB驱动不自动响应gin.Context超时；必须用db.QueryContext等带context方法，并分层设置连接池参数与查询隔离。
数据库慢查询会拖垮整个Gin服务，不是加个context.WithTimeout就能解决的——它只管请求生命周期，不管DB连接池里那几个卡住的db.Query。
为什么Gin中间件拦不住慢SQL
Gin的中间件运行在HTTP请求上下文里，而数据库查询一旦发起，就脱离了gin.Context的超时控制。即使你在中间件里调用c.Request.Context().Done()，底层database/sql驱动（比如pgx或mysql）并不会自动响应这个信号，除非显式传入带超时的context.Context。
- 常见错误：直接用
db.Find(&result)这类无context方法，完全忽略超时 - 误区：以为
gin.Context能穿透到DB驱动层 - 后果：一个慢查询占满连接池，后续所有请求排队等待，
http: Accept error: accept tcp: accept4: too many open files随之而来
必须用带context的DB操作函数
所有数据库交互必须使用接受context.Context参数的方法，且该context应来自c.Request.Context()或其派生（如context.WithTimeout(c.Request.Context(), 2*time.Second)）。
-
db.WithContext(c.Request.Context()).Where(...).Find(&result)（GORM v2+） -
db.QueryContext(c.Request.Context(), "SELECT ...", args...)（标准database/sql） - 避免
db.First()、db.Create()等无context变体，它们不响应取消 - 注意GORM v1不支持context，必须升级到v2或手动包装
连接池与超时要分层设置
单靠SQL超时不够，得配合连接池级防护：
-
db.SetMaxOpenConns(20)：防雪崩，别设成0或过大 -
db.SetConnMaxLifetime(10 * time.Minute)：避免长连接老化失效 -
db.SetConnMaxIdleTime(5 * time.Minute)：及时回收空闲连接 - 最关键：
db.SetMaxIdleConns(10)，让空闲连接数 ≤ 打开数，否则idle连接堆积仍会耗尽文件描述符
这些值不是越大越好，要结合压测结果调——比如QPS 500时，MaxOpenConns=30可能刚够，设成100反而引发锁竞争。
慢查询必须隔离到独立DB实例
读多写少、报表类、聚合统计等慢查询，不能和主业务共用同一个*gorm.DB实例。否则一个GROUP BY + ORDER BY + LIMIT就能让订单接口一起卡住。
- 方案一：启动时初始化两个DB对象，分别指向主库和只读从库（或专用分析库）
- 方案二：用GORM的
Session机制临时切换配置：db.Session(&gorm.Session{Context: slowCtx}).Raw("...").Scan(&res) - 方案三：更彻底的——用
sqlmock或go-sqlmock在测试中注入慢查询延迟，验证隔离逻辑是否生效
真正难的不是加隔离，而是识别哪些查询该隔离。别只看执行时间，重点盯EXPLAIN ANALYZE里是否出现Seq Scan、Sort、Hash Join这类高成本操作——它们才是慢查询的根因，超时只是症状。
