mysql深分页性能骤降是因为offset需顺序扫描并丢弃前offset行，无法跳过；游标分页（where > last_value）和延迟关联可优化，但任意页码跳转仍存瓶颈。
为什么 OFFSET 在百万级数据下会拖垮分页性能
因为数据库执行 OFFSET 1000000 LIMIT 20 时，仍需扫描前 100 万行才能跳到目标位置，即使有索引，B+ 树也要回表或遍历大量索引节点。GORM 默认的 Offset() + Limit() 写法在 ORDER BY id 场景下尤其危险——MySQL 8.0 以前几乎无法用上覆盖索引优化。
实操建议：
- 确认主键或排序字段（如
created_at）已建联合索引，例如INDEX idx_status_created (status, created_at)，避免排序走 filesort - 禁用
Offset()，改用「游标分页（cursor-based pagination）」：用上一页最后一条记录的created_at和id作为下一页查询条件 - 若必须用页码（如后台管理），限制最大页码（如
page ），并在日志中告警超限请求
GORM 中实现安全的游标分页（WHERE ... AND ... ORDER BY ... LIMIT）
核心是把「第 N 页」转换成「大于上一页末条记录」，绕过 OFFSET。GORM 本身不提供开箱即用的游标分页方法，需手动拼条件。
实操建议：
- 前端传参用
cursor=2024-05-01T12:00:00Z_123456（时间戳+ID 组合），后端拆解为lastCreatedAt和lastID - GORM 查询写法：
db.Where("created_at > ? OR (created_at = ? AND id > ?)", lastCreatedAt, lastCreatedAt, lastID). Order("created_at ASC, id ASC"). Limit(20). Find(&results) - 务必在
ORDER BY字段和WHERE字段上建联合索引，否则OR条件会让索引失效 - 首次请求无 cursor 时，用
WHERE created_at > '0001-01-01'起始，避免全表扫
Count() 在百万表上为什么不能直接调用
db.Model(&User{}).Count(&total) 会生成 SELECT COUNT(*) FROM users WHERE ...，在 InnoDB 下需扫描满足条件的所有行（即使加了索引），I/O 和 CPU 开销陡增，且阻塞其他写操作。
实操建议：
- 业务允许误差时，用 MySQL 的近似统计：
SELECT table_rows FROM information_schema.tables WHERE table_name = 'users'（仅适用于无复杂 WHERE 条件） - 带条件的精确总数，改用「延迟计数缓存」：用户访问第一页时异步触发
COUNT并存入 Redis，有效期设为 5 分钟；后续请求读缓存，过期再异步刷新 - 若必须实时总数（如后台报表），单独走只读从库执行
COUNT，并加SET SESSION optimizer_search_depth = 3防止优化器耗尽 CPU
分页结果中 ID 不连续导致游标错位怎么办
当按 created_at 排序、但同一秒内有多条记录时，仅靠时间戳做游标会漏数据（比如两条记录 created_at 相同，但 id 不同，WHERE created_at > ? 会跳过第二条）。
实操建议：
- 游标必须包含「排序字段全集」：如果
ORDER BY created_at DESC, id DESC，则 cursor 必须是created_at_id二元组，解码后用于两个条件 - 在 GORM 查询中显式补全所有排序字段的比较逻辑，例如：
db.Where("(created_at - 禁止在游标分页中使用
SELECT *，只查必要字段，减少网络传输和 GC 压力；大字段（如TEXT）用SELECT id, created_at, ...显式声明
游标分页真正难的不是写法，而是确保排序字段组合在任何写入场景下都唯一且稳定——比如用 id 代替 updated_at 作次要排序字段，因为自增 ID 永远不会重复或回退。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
