gorm深度分页耗尽数据库连接句柄，因mysql执行offset需扫描并丢弃前n行，导致单次查询变慢、锁持有延长、事务未及时释放，连接池被占满；应改用基于排序字段（如id）的游标分页，手动实现where条件+order+limit。
为什么 GORM 的深度分页会耗尽数据库连接句柄？
因为 LIMIT + OFFSET 查询在 MySQL 中必须扫描并丢弃前 OFFSET 行，当 OFFSET 达到几十万甚至百万级时，单次查询执行时间拉长、锁持有时间变久、事务未及时释放，最终导致连接池中大量 *sql.Conn 长时间占用，新请求不断排队等待，触发 sql: connection pool exhausted 错误。
GORM 中禁用 OFFSET 的替代写法（游标分页）
游标分页不依赖行号，而是基于上一页最后一条记录的排序字段值继续查。GORM 本身不内置游标逻辑，但可手动拼装条件实现：
- 必须确保排序字段（如
id或created_at）有唯一性或组合唯一性，否则可能漏/重数据 - 避免用
ORDER BY RAND()或非索引字段排序，否则无法走索引，照样慢 - 示例：查下一页（假设上一页最后一条是
id = 1005）：db.Where("id > ?", 1005).Order("id ASC").Limit(20).Find(&users) - 若需倒序分页（最新在前），则用
WHERE created_at + <code>ORDER BY created_at DESC
GORM 查询前强制加 LIMIT 防失控
即使业务层没显式写 LIMIT，也要在 GORM 初始化时设置默认限制，防止开发疏忽导致全表扫描：
- 使用
Session绑定默认限制：db.Session(&gorm.Session{PrepareStmt: true}).Limit(1000).Find(&results) - 更稳妥的是在中间件或 DAO 层统一拦截无
LIMIT的查询，抛出错误或自动截断（例如超过 10000 就报"OFFSET too large, use cursor pagination"） - 注意：GORM 的
Limit(0)不代表不限制，而是清空已设 limit；真正“不限”是不调用Limit，所以检测逻辑要判断stmt.Limit == nil
连接池与超时配置必须同步收紧
光改 SQL 不够，GORM 默认连接池参数过于宽松，容易掩盖问题：
- 显式设置
MaxOpenConns（建议 ≤ 50）、MaxIdleConns（建议 =MaxOpenConns）、ConnMaxLifetime（建议 1h） - 给每个查询加上下文超时：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() db.WithContext(ctx).Where(...).Find(&users)
- 启用 GORM 的
Logger并过滤出执行时间 > 1s 的慢查询，持续监控OFFSET > 10000的语句
