大家好，我是小米，互联网一线技术分享者。今天聊一个在 MySQL 面试中频繁出现的问题：如何查找第 100 万页？

使用者痛点一的观点是，分页性能急剧下降

当数据量达到几千万甚至上亿时传统的LIMIT offset。size分页会让 MySQL 扫描海量行后才丢弃前面的记录，这导致：

• CPU 与 I/O 资源被大量浪费。
• 响应时间从毫秒级膨胀到秒级甚至更长。
• 业务程序出现卡顿、查询超时。

至于使用者痛点二，业务层面无法符合使用者需求

普通分页只能满足“翻页”功能。但面对大规模数据时：

• 使用者需要翻到第 100 万页几乎不可能；
• 频繁请求导致数据库压力骤增；
• 前端无论是“上一页/下一页”还是无限滚动，都难以实现平滑体验。话说回来，

为什么超大分页慢？老实说，

"扫描+丢弃"

Select * from orders limit 9999999,20;

MySQL 会先扫描前九千九百九十九万行。接下来丢弃，再返回 20 条。怎么说呢，这种做法在页码偏后时会变成指数级消耗。

利用索引定位起点

"不要用 offset"

• Select * from orders where id> last_seen_id order by id asc limit 20;

延迟关联

"先取主键，再回表"

• Select * from t join orders o on o.id = t.id; 子查询只走索引，主查询只读单行，极大降低扫描量。老实说，

基于游标的分页

• "边走边翻页"
• Select * from orders where created_at> last_timestamp order by created_at asc limit 20; 每次查询都从上一次结束的位置继续，提高效率。

业务层面的调整策略

• "限制最大页数": 给程序设置一个合理上限，例如最多允许浏览前五十万条记录。超出范围则提示“请先筛选条件”。说起来，
• "搜索+过滤结合": 使用者先输入关键字或时间范围。让数据库只在缩小后的子集内分页。
• "无限滚动 + 异步加载": 前端采用懒加载。只在使用者滚动到底部时发起新请求，从而分散峰值压力。
• "缓存热点数据": 对常访问的数据块使用 Redis 或 Memcached 做缓存，减少对磁盘 I/O 的依赖。

MySQL .x 新特性武器箱

1. windows 函数 + row_number

• = Select *,row_number over as rn from orders where rn 娱乐ween 9999999*20+1 and *20;

• =

  CtePagination AS (
  SELECT *。ROW_NUMBER OVER AS rn
  FROM orders
  )
  SELECT * FROM CtePagination WHERE rn BETWEEN :start AND :end;

升级到 MySQL .x 后对主键列进行更高效排序与定位，可进一步提高跳转速度。怎么说呢，

小结

• 大数据分页最主要问题是"扫描过多，无意义读取";怎么说呢，
• 用索引、游标或窗口函数可以显著减少扫描量；
• 在业务层面限制页数、增加过滤、异步加载等手段能进一步缓解压力；
• 熟悉 MySQL .x 的新特性不仅能写出更优方案，还能给面试官留下深刻印象。