17370845950

推荐使用游标分页替代 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 超时设置，防雪崩。