GORM分页慢主因是未优化SQL执行计划、索引缺失或误用OFFSET分页；应改用游标分页、确保ORDER BY字段有覆盖索引、避免SELECT*、对Preload外键建索引、Count与Find拆开执行。
GORM 分页慢，90% 不是框架问题，而是没看执行计划、没建对索引、或用了错误的分页模式。
为什么 OFFSET 分页在 GORM 里越查越慢
用 db.Offset(10000).Limit(20).Find(&users) 这类写法，数据库必须先扫描前 10000 条记录，再取后 20 条——数据量一过百万，type=ALL 就稳了。MySQL/PostgreSQL 都不优化 OFFSET 的跳过逻辑，它本质是“先读再丢”。
常见错误现象：EXPLAIN 显示 rows 值远大于 Limit，且 Extra 出现 Using filesort 或 Using temporary。
- 高频列表页（如后台用户管理）必须弃用
Offset，改用基于游标的分页（cursor-based），例如WHERE id > ? ORDER BY id LIMIT 20 - 若必须用
Offset，确保ORDER BY字段有索引，且该索引能覆盖查询条件（比如WHERE status = ? ORDER BY created_at→ 索引应为(status, created_at, id)） - 避免
SELECT *配合大Offset：用Select("id,name,email")减少传输和排序开销
EXPLAIN 是唯一可信的“真相探测器”
GORM 日志里看到的 SQL 只是表象；真正决定快慢的是数据库执行计划。不跑 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON（MySQL 8.0+），你就是在猜。
关键看三项：type（是否走索引）、key（用了哪个索引）、rows（预估扫描行数）。
- 如果
type是ALL或index，说明没走有效索引，立刻检查 WHERE 字段是否在索引中 - 如果
key为空，或显示key_len远小于索引总长度，说明只用了索引前缀（字段顺序错或类型不匹配） - 对
Preload生成的 JOIN 查询，分别对主表和关联表的子查询单独EXPLAIN，N+1 往往藏在 Preload 的隐式语句里
GORM 分页 + Preload 的索引组合陷阱
写 db.Preload("Orders").Order("users.created_at DESC").Limit(20).Find(&users) 看似合理，但 GORM 会生成两条 SQL：一条查 users，一条用 IN (id1,id2,...) 查 orders。第二条若没索引，IN 列表一长就崩。
典型错误场景：orders 表没对 user_id 建索引，或建了但类型与 users.id 不一致（比如一个是 BIGINT，一个是 INT）。
- 所有外键字段（如
user_id,category_id）必须显式建索引，且类型严格匹配主表主键 - 复合索引优先于单列索引：如分页常按
status和created_at筛选，则建(status, created_at, id)而非两个单列索引 - 用
db.Session(&gorm.Session{PrepareStmt: false})关闭预编译，避免IN参数过多时 MySQL 报max_prepared_stmt_count错误
Count 查询必须独立，且带相同 WHERE 条件
很多人写 db.Where(...).Limit(20).Count(&total).Find(&users)，以为一次调用搞定总数和数据——但 GORM 会把 Count 当作子查询嵌套进主 SQL，导致全表扫描加重。
更糟的是，如果 WHERE 条件含变量，而 Count 和 Find 的参数绑定不一致（比如一个传指针、一个传值），结果可能错乱。
- 拆成两步：
db.Where(...).Count(&total)+db.Where(...).Order(...).Limit(20).Find(&users)，确保条件完全一致 - Count 语句无需
SELECT全字段，GORM 默认只SELECT COUNT(*)，但务必确认它没被钩子或 Scope 意外改写 - 对超大数据集，考虑用近似统计（如 PostgreSQL 的
reltuples）或业务层缓存总数，避免每次请求都 COUNT
最易被忽略的一点：GORM 的 Preload 在分页后才执行，但它加载的关联数据量取决于原始查询结果数（比如 Limit 20 就只 Preload 20 个用户的订单），这点没错；但如果你在 Preload 后又对 users 切片做了二次过滤或排序，就等于把性能优化的努力全白费了——数据库已经按最优路径执行了，Go 层不该再做本该由 SQL 完成的事。
