推荐使用游标分页替代 offset/limit，以单调递增字段（如 ID 或 created_at+id 组合）作游标，配合联合索引、延迟关联、只查必要字段及响应式分页元信息设计，保障大数据下分页性能与稳定性。
在 Go 中实现 RESTful 分页接口处理大数据查询，核心是避免全表扫描、减少内存占用、保证响应稳定，并兼顾用户体验。关键不在于“一次查多少”，而在于“怎么查得稳、返回得准、后续能续”。
用游标分页（Cursor-based Pagination）替代传统 offset/limit
当数据量达百万级以上，offset N limit M 会因跳过前 N 行导致数据库执行计划变慢（尤其在无覆盖索引时），延迟陡增且结果易错位（新数据插入导致页偏移）。游标分页以“上一页最后一条记录的唯一有序字段值”作为下一页起点，性能稳定、无跳页风险。
- 推荐使用单调递增字段（如自增 ID、created_at + id 组合）作游标；
- 请求示例：
/api/items?cursor=12345&limit=20，表示“取 ID > 12345 的前 20 条”； - 响应中返回下一个游标：
"next_cursor": "12365"，客户端只需透传，无需计算； - 注意：需确保游标字段有索引，且排序方向与查询一致（如
ORDER BY created_at DESC, id DESC）。
数据库层优化：索引、延迟关联与只查必要字段
分页慢常因 SELECT * + JOIN 导致大量 I/O 和临时表。应从查询源头收敛数据体积。
- 只 SELECT 接口需要的字段，避免
*； - 对游标字段、过滤字段、排序字段建立联合索引（如
INDEX idx_status_created_id (status, created_at, id)）； - 大表关联用延迟关联（deferred join）：先用子查询拿到主键列表，再 JOIN 取详情，减少中间结果集；
- 考虑物化视图或汇总表缓存高频分页场景（如“最近 7 天活跃用户列表”）。
API 设计与响应结构保持语义清晰
RESTful 分页不是拼参数，而是通过响应体显式表达分页上下文，降低客户端理解成本。
- 响应统一包装分页元信息：
data、pagination（含has_next、next_cursor、count等）； - 不暴露 total_count（大数据下 COUNT(*) 极其昂贵），可用近似值或省略；
- 限制最大 limit（如 100），防止恶意请求拖垮 DB；
- 支持可选排序字段（如
?sort=created_at:desc），但需白名单校验，避免 SQL 注入或无效索引。
Go 实现要点：用 sqlx 或 pgx 配合 struct 扫描，避免手动拼 SQL
用原生 database/sql 易出错，推荐
sqlx（兼容 MySQL/PostgreSQL）或 pgx（PostgreSQL 高性能首选）。
- 游标查询示例（PostgreSQL）：
SELECT id, name, created_at FROM items WHERE status = $1 AND (created_at, id) > ($2, $3) ORDER BY created_at DESC, id DESC LIMIT $4； - 用
sqlx.Select()或pgxpool.Query()扫描到结构体切片，自动映射字段； - 游标值从上一页最后一条记录提取，注意空结果时 next_cursor 应为空字符串或 null；
- 加 context.WithTimeout() 控制查询超时，配合 HTTP 超时设置，防雪崩。
