大数据分页应采用游标分页而非OFFSET，用有序字段（如id或create_time）做条件筛选，配合联合索引提升性能；避免COUNT(*)全表扫描，限制深度、缓存热点页并校验游标合法性。
大数据量分页不能靠 OFFSET 硬拖，否则越往后翻越慢，甚至锁表、超时。核心思路是：用有序字段做游标（Cursor-based Pagination），避开 OFFSET 的全扫描代价。
用主键或唯一时间戳做游标分页
假设表有自增主键 id 或带索引的 create_time，每次查询只取“大于上一页最后一条值”的下 N 条记录：
- 第一页：
SELECT * FROM orders WHERE status = 1 ORDER BY id ASC LIMIT 20; - 第二页（已知上页最后 id=12345）：
SELECT * FROM orders WHERE status = 1 AND id > 12345 ORDER BY id ASC LIMIT 20; - 倒序翻页同理，改用
id + <code>ORDER BY id DESC
关键点：必须有高效索引支撑排序字段（如 (status, id) 联合索引），且字段值尽量不重复；若用时间戳，需搭配主键去重（如 WHERE create_time > '...' OR (create_time = '...' AND id > ...)）。
避免 OFFSET 的典型误用场景
以下写法在千万级表上极易变慢：
-
SELECT * FROM logs ORDER BY id DESC LIMIT 100000, 20—— MySQL 仍要定位前 10 万行 -
SELECT COUNT(*) FROM huge_table配合分页总数显示 —— 全表扫描开销巨大 - 前端传
page=1000&size=20，后端直接算OFFSET 19980—— 用户可能跳转到极深页码，但实际业务极少需要
建议：禁用传统 page/size 接口；改用游标参数（如 cursor=12345）；总数可估算或直接不返回。
覆盖索引 + 延迟关联优化查询性能
当分页字段和查询字段不一致时（比如按 user_id 排序，但要查 user_name, amount, remark），避免回表放大 IO：
- 先用覆盖索引查出 ID 列表：
SELECT id FROM orders WHERE status = 1 AND user_id > 1000 ORDER BY user_id LIMIT 20 - 再用这些 ID 关联原表取详情：
SELECT o.* FROM orders o JOIN (...) t ON o.id = t.id
MySQL 会自动优化为延迟关联（Deferred Join），大幅减少大字段读取次数。注意子查询结果集不宜过大（一般 ≤ 数百条），否则 JOIN 成本上升。
业务层配合：限制深度、缓存热点页、预加载
技术方案需结合业务习惯落地：
- 限制最大游标偏移（如只允许向前翻 5000 页），超出则提示“已到底部”或引导搜索
- 对首页、昨日数据等高频页，缓存结果集（Redis 存 JSON 数组或序列化对象）
- 移动端下拉刷新时，提前异步加载下一页 ID 游标，提升滑动流畅感
不复杂但容易忽略：游标值要校验合法性（非空、数字、存在性），防止恶意构造参数绕过权限或引发 SQL 错误。
