GORM框架分页执行计划与索引调优-Golang-PHP中文网

gorm的limit+offset分页在数据量超10万后性能断崖式下跌，根本原因是mysql/postgresql必须扫描并丢弃前n行，加索引仅缓解、无法根治；应改用游标分页或索引优化。

gorm框架分页执行计划与索引调优

Offset 分页在数据量超 10 万后性能断崖式下跌，不是 GORM 写得不好，是 MySQL/PostgreSQL 执行计划本身要求它必须扫描并丢弃前 N 行——加索引只能缓解，不能根治。

为什么 EXPLAIN 显示 rows 很大，但 LIMIT 很小？

执行 EXPLAIN SELECT * FROM users ORDER BY id DESC LIMIT 20 OFFSET 100000 时，rows 列常显示 100020，甚至更高。这不是误报，而是数据库真实评估的扫描行数：它得先按 id DESC 走索引遍历 100000 条，再丢弃，最后取 20 条。

B+ 树索引无法“跳转”到第 N 条，只能从根节点逐层定位、回溯，OFFSET 越大，树遍历路径越长
即使 id 有主键索引，OFFSET 100000 仍需在索引页中跳过 10 万次指针移动
如果排序字段不是索引前缀（比如 ORDER BY status, created_at 但只建了 created_at 单列索引），会触发 Using filesort，性能雪崩
用 SELECT id, name 替代 SELECT * 可减少回表，但扫描行数不变——优化点不在传输，而在扫描本身

游标分页的执行计划怎么才算合格？

合格的游标分页 SQL 必须让 EXPLAIN 的 type 是 range 或 index，且 rows 接近你设的 LIMIT 值（比如 LIMIT 20 对应 rows ≈ 20–50）。

GORM框架 1.30.3

GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。

下载

错误写法：WHERE created_at —— 若 <code>created_at 有重复值，可能漏掉同时间的其他记录
正确写法：WHERE (created_at, id) ，并确保联合索引为 <code>INDEX idx_created_id (created_at, id)
MySQL 8.0+ 支持行构造器比较，PostgreSQL 需展开为 created_at
GORM 中避免字符串拼游标：db.Where("(created_at, id) ，其中 <code>cursorValue 是 []interface{}{"2024-01-01", 1000}

哪些索引对分页真正有效？

不是所有“带排序字段的索引”都管用。索引必须覆盖查询的完整排序+过滤路径，否则仍会回表或全扫。

单字段分页（如 ORDER BY id ASC）：主键索引天然生效，无需额外建索引
时间线分页（如 ORDER BY created_at DESC, id DESC）：必须建联合索引 INDEX idx_created_id (created_at, id)，顺序不能颠倒
带 WHERE 条件的分页（如 WHERE status = ? ORDER BY created_at DESC）：索引应为 INDEX idx_status_created (status, created_at)，把等值字段放前面
别建 INDEX (created_at) 然后以为够了——当查 WHERE deleted = false 时，这个索引完全用不上

Count(*) 全表扫描能绕过去吗？

能，而且多数场景下应该绕。执行 EXPLAIN SELECT COUNT(*) FROM users WHERE status = 'active'，若没走索引，rows 就是全表行数。

前端只要“是否有下一页”，就查 LIMIT size + 1，多一条判断 len(results) > size，彻底省掉 COUNT
必须显示总数时，优先缓存：比如后台配置类数据，用 Redis 存 cache:users:total，变更时原子更新
实在要查，别用 db.Model(&User{}).Where(...).Count() —— 它可能忽略 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)
注意：MySQL 的 SELECT COUNT(*) 在 InnoDB 下仍是聚簇索引遍历，不是元数据读取，大数据量一样慢