limit + offset 性能差因数据库需扫描并丢弃前 offset 行，即使有索引也无法跳转到第 n 行；需用覆盖索引（含 where、order by 和 select 所有字段）配合显式 select() 或游标分页优化。
为什么 LIMIT + OFFSET 会拖垮分页性能？
因为数据库必须扫描并丢弃前 OFFSET 行，哪怕你只想要 20 条——10 万行偏移意味着至少扫描 10 万行。这不是 GORM 的锅，是 MySQL/PostgreSQL 的执行机制决定的。即使 id 有索引，B+ 树也无法跳转到“第 N 行”，只能逐节点遍历。
更隐蔽的问题是：如果分页时用了 ORDER BY created_at DESC, id DESC，但没建对应复合索引，数据库就会回表或全索引扫描，LIMIT 20 OFFSET 100000 可能直接触发 filesort + temporary table。
- 避免在分页查询中用
SELECT *：它让覆盖索引失效，强制回表查完整行 - 确认排序字段是否走索引：用
EXPLAIN ANALYZE看key和Extra（如Using index才表示命中覆盖索引） - 不要依赖
Count(*)获取总条数：它本身就会全表扫描，QPS 下降明显
如何设计覆盖索引支撑分页？
覆盖索引要求：查询所需的所有字段（包括 SELECT 列、WHERE 条件列、ORDER BY 列）都包含在同一个索引里，且顺序合理。
例如，分页接口常查：SELECT id, title, status, created_at FROM posts WHERE status = ? ORDER BY created_at DESC, id DESC LIMIT 20 OFFSET ?。对应索引应为：
CREATE INDEX idx_posts_status_created_id ON posts (status, created_at DESC, id DESC);
注意三点：
- 索引首字段必须是
WHERE中的等值条件（status），否则无法高效过滤 -
ORDER BY字段必须严格按顺序、方向一致地跟在后面（created_at DESC, id DESC） - 所有
SELECT字段（id, title, status, created_at）中，title不在索引里 → 必须加进索引，或改查法（见下一条）
GORM 中怎么写才能命中覆盖索引？
关键不是“怎么写 GORM”，而是“GORM 生成的 SQL 是否满足覆盖索引条件”。默认 db.Find(&posts) 会查所有字段，破坏覆盖性。
必须显式指定字段，用 Select() 控制输出列：
db.Table("posts").
Select("id, title, status, created_at").
Where("status = ?", "published").
Order("created_at DESC, id DESC").
Limit(20).
Offset(100000).
Find(&posts)
这样生成的 SQL 才可能命中 idx_posts_status_created_id（前提是索引含 title）。若不想把 title 加进索引（它可能很长），就换思路：
- 用游标分页，只依赖
created_at和id排序和定位，SELECT也只取这两个字段 + 主键 - 前端分页只展示摘要，详情用
id单条查（此时id主键索引即可） - 禁用
Find()，改用Raw()手写 SQL，彻底掌控字段和索引匹配
游标分页 + 覆盖索引才是高可靠组合
Offset 分页本质不可扩展，而游标分页天然适配覆盖索引：你只需要上一页最后一条的 created_at 和 id，就能写出高效范围查询。
示例（GORM 写法）：
db.Table("posts").
Select("id, title, status, created_at").
Where("status = ? AND (created_at, id)
<p>这个查询能完美利用 <code>idx_posts_status_created_id</code>，且不依赖 <code>OFFSET</code>。但要注意：</p>
- 复合条件
(created_at, id) 在 MySQL 8.0+ / PostgreSQL 中才原生支持；低版本得拆成 <code>created_at - 游标值必须从当前页**最后一条**取，不能用第一条，否则漏数据
- 排序字段必须非空、高基数、有索引——
created_at比status更适合作为主排序字段
真正卡住性能的，往往不是 GORM 写法多炫，而是索引没对上、字段没精简、排序没固化。覆盖索引不是银弹，但它和游标分页绑在一起，是目前最可控、最可测的大数据量分页解法。
