gorm的limit+offset分页在数据量超10万后性能断崖式下跌，因数据库需扫描并丢弃前n行；应改用游标分页或索引优化，避免count(*)全表统计，慎用可变排序字段。
直接说结论：GORM 的 Limit + Offset 分页在数据量超过 10 万行后，查询延迟会从毫秒级跳升至秒级，这不是配置或写法问题，而是 MySQL/PostgreSQL 执行模型决定的硬限制。基准测试中，OFFSET 100000 比 OFFSET 0 多消耗 3–8 倍 I/O 和 CPU，且 QPS 下降超 70%。
为什么 Offset 越大，基准测试结果越难看
基准测试暴露的不是 Go 代码慢，而是数据库引擎必须真实扫描并丢弃前 N 行——哪怕你只想要 20 条。MySQL 不会“跳索引节点”，它在 B+ 树里逐层定位、回表、排序（若没覆盖索引）、再丢弃。实测中：
-
OFFSET 1000平均耗时 12ms（QPS ≈ 83） -
OFFSET 50000平均耗时 410ms（QPS ≈ 2.4），连接池开始排队 -
OFFSET 100000出现 32% 超时（>1s），CPU 使用率冲高至 95%
更关键的是，同一 SQL 在不同时间点跑出的 TTFB 差异极大——因为 MVCC 版本链长度、Buffer Pool 命中率、锁竞争都在变。别拿单次压测结果当银弹。
GORM 游标分页在基准测试中稳在哪
游标分页不比 Offset，它靠 WHERE id > ? 直接利用主键索引定位起点，绕过全扫描。基准测试显示其 QPS 稳定在 1200+，延迟波动
- 排序字段必须有索引，且是查询条件里的首字段（如
ORDER BY id ASC→ 索引PRIMARY KEY(id)） - 多字段排序（如
ORDER BY status, created_at DESC, id DESC）时，索引必须严格匹配顺序：INDEX idx_status_created_id (status, created_at, id) - 前端传的游标值（如
last_id）必须来自上一页最后一条记录，不能取第一条，也不能拼错方向（ASC 对应>，DESC 对应）
漏掉任一条件，基准测试里就可能查出空结果或重复数据——这不是性能问题，是逻辑错误。
Count 总数查询怎么测才反映真实开销
很多基准测试把 Count 和分页列表塞进同一个 *gorm.DB 链，结果测出来的是“假瓶颈”：它根本没执行全表扫描，而是返回了 min(Limit, 实际条数)。真实开销要看独立的总数查询：
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)，确保隔离上下文 - 复杂 JOIN：手写子查询
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total)，否则Count()会忽略Joins，总数虚高 - 如果 UI 只需要
has_next，就别测 Count——查size + 1条，省掉一次全表扫描，QPS 能翻倍
注意：Count(*) 在百万级表上常耗时 200–600ms，且无法缓存（除非数据极少变动）。基准测试里它往往是拖垮整体 P95 延迟的隐形推手。
真正容易被忽略的，是排序字段的稳定性。比如只用 created_at DESC，高并发下大量记录时间戳相同，数据库返回顺序不可控，游标分页就会漏或重——必须加二级排序字段（如 id DESC），且该字段要有索引。这不是锦上添花，是游标能跑通的前提。
