offset + limit 在高并发下变慢是因为数据库需扫描并跳过 offset 行，偏移越大，I/O 与 CPU 开销越高，易引发慢查询和资源争抢；应改用游标分页或 ID 范围查询，并辅以缓存与熔断降级。
为什么 offset + limit 在高并发下会变慢
因为数据库要先跳过前面 offset 行数据，再取 limit 行——跳得越远，扫描的行越多。当 offset = 1000000 时，MySQL 可能要读取上百万行才开始返回结果，CPU 和 I/O 压力陡增，响应时间飙升，还容易触发慢查询告警。
更糟的是，并发请求多时，这些大偏移量查询会排队争抢索引页、锁资源，甚至拖垮整个主库。
- 真实场景中，
SELECT * FROM article ORDER BY id DESC LIMIT 1000000, 20可能耗时 2s+，而LIMIT 0, 20只需 5ms - 即使加了
id索引，B+ 树仍需逐层遍历到第 1000000 个叶子节点位置 - 分页深度越大，缓存（如 Query Cache 已弃用，或 Redis 分页结果）命中率越低，重复计算越多
用游标分页（Cursor-based Pagination）替代 offset
核心是“记住上一页最后一条记录的排序字段值”，下一页直接从该值之后查起，避免跳行。适用于按主键或时间戳等单调字段排序的场景。
比如文章列表按 created_at DESC 排序，第一页取到第 20 条的 created_at = '2024-05-20 14:30:00'，第二页就查：
立即学习“PHP免费学习笔记（深入）”；
SELECT * FROM article WHERE created_at < '2024-05-20 14:30:00' ORDER BY created_at DESC LIMIT 20
- 必须确保排序字段有索引，且值唯一或配合其他字段去重（如
(created_at, id)联合索引） - 前端传参不再是
page=2，而是cursor=2024-05-20T14:30:00Z或last_id=123456 - 不能跳页（如直接跳到第 100 页），但高并发下这反而是优势：减少无效扫描，降低 DB 压力
对 ID 主键分页做范围预判与缓存
如果业务允许按 id ASC 分页（如后台管理），可提前估算每页 ID 区间，用 BETWEEN 或 >= AND 替代 LIMIT offset, size。
例如已知每页 20 条，第 1 页 ID 是 1–20，第 2 页是 21–40……那么第 50000 页可直接查：
SELECT * FROM article WHERE id BETWEEN 999981 AND 1000000 ORDER BY id ASC
- 前提是 ID 连续或基本连续；若存在大量删除，可用
SELECT id FROM article ORDER BY id ASC LIMIT 999980, 20先查 ID 列表，再IN关联主表（两次查询，但比大 offset 快得多） - 把常用页码的 ID 范围缓存到 Redis，比如
page:article:50000→[999981,1000000]，TTL 设为 1 小时，减轻 DB 查询压力 - 注意：此法不适用于
ORDER BY RAND()或复杂动态排序
PHP 层加轻量级熔断与降级逻辑
当分页接口被高频刷或慢查询堆积时，不能让 PHP 进程卡死或 DB 连接池耗尽。可在 PDO 查询前加简单判断：
- 用
microtime(true)记录查询开始时间，执行超 800ms 自动中断并返回缓存旧数据或提示“稍后重试” - 统计最近 1 分钟内该分页接口的平均耗时，若超过阈值（如 1.2s），自动切换到游标分页模式或返回兜底静态页
- 对
offset > 10000的请求，直接拒绝并返回 HTTP 400，附带建议使用搜索或筛选缩小结果集
高并发分页真正的瓶颈往往不在代码写法，而在“是否真需要翻到第 10 万页”。游标分页不是银弹，但它把性能问题从“数据库能不能扛住”变成了“业务要不要支持这个操作”。
