处理千万级数据分页的核心思路是避免使用limit offset，转而采用基于索引范围的游标分页。1. 使用自增主键或时间戳作为游标字段，首次查询通过order by和limit获取第一页数据，并记录最后一条记录的id；2. 查询下一页时，在where条件中加入游标字段大于上一页最后一个id的条件，结合order by和limit实现高效分页；3. 该方法利用索引快速定位起始位置，避免扫描和丢弃大量数据，显著提升性能；4. 局限在于仅支持“下一页”模式，无法直接跳转指定页码，适用于无限滚动等场景；5. 对于需跳页的后台系统，可采用延迟关联优化传统分页，或使用缓存、预计算总数等方式平衡性能与体验；6. 总数统计应避免实时select count(*)，可通过缓存、估算或ui优化减少用户等待。此策略能有效解决大偏移量带来的性能瓶颈，是千万级数据分页的最优解。
处理千万级数据分页，核心思路在于避免MySQL扫描并丢弃大量不必要的数据。简单粗暴的
LIMIT OFFSET在数据量一大就彻底歇菜，因为它会从头开始数，数到你指定的偏移量，再取N条。真正的优化，通常是利用索引，将分页查询转化为基于范围的查询，比如使用上一页的最后一个ID作为下一页的起始点。
解决方案
解决千万级数据分页的根本之道，在于将传统的
LIMIT offset, limit模式，转换为基于索引范围的查询。最常见且高效的策略是“游标分页”或“ID分页”。
具体来说，就是不使用
OFFSET，而是利用表中的唯一递增字段（通常是主键ID，或者一个有序的时间戳字段）来定位下一页的起始位置。
首次查询：
SELECT id, column1, column2 FROM your_table WHERE some_condition ORDER BY id ASC LIMIT 100;
这条查询会获取第一页的100条数据。你拿到这100条数据后，记录下其中最大的
id值（比如是
max_id_on_current_page）。
查询下一页：
SELECT id, column1, column2 FROM your_table WHERE some_condition AND id > max_id_on_current_page ORDER BY id ASC LIMIT 100;
通过这种方式，MySQL可以直接利用
id上的索引，快速定位到
max_id_on_current_page之后的数据，避免了扫描前面大量的、你根本不需要的数据。如果需要倒序，逻辑类似，只是
ORDER BY id DESC和
id < min_id_on_current_page。
为什么简单的 LIMIT OFFSET
在千万级数据下会慢？
这问题，说实话，很多刚接触数据库优化的朋友都会踩坑。当你写下
SELECT * FROM large_table ORDER BY id LIMIT 1000000, 10;这样的语句时，MySQL内部并不是“跳过”一百万条数据那么简单。它实际上是老老实实地从头开始，读取并处理了1000010条数据，然后才把前面的1000000条给扔掉，只留下最后10条给你。
这就像你让快递员从北京往上海送包裹，结果他得先把北京到南京的包裹都搬上车，再从车上扔下去，才开始送上海的。想象一下，如果偏移量（OFFSET）特别大，比如几百万、上千万，那这个“扔掉”的成本就变得极其高昂。即使你的
ORDER BY字段有索引，MySQL也得遍历这个索引树，找到第1000001个位置，这本身就是个耗时的操作。尤其当
SELECT *涉及大量列，或者数据行很宽时，每次读取并丢弃的IO和CPU开销都会成倍增加。这就是为什么简单分页在数据量大时，会让你感到绝望的原因。
基于游标（ID或时间戳）的分页优化实践
在我看来，基于游标的分页，是处理大表分页最优雅也最有效的方案之一。它本质上是把“跳过多少行”的逻辑，转换成了“从哪里开始取”的逻辑。
我们通常会利用表里一个连续递增且唯一的字段，比如自增主键ID，或者一个精确到毫秒的时间戳字段。
具体做法：
-
初始查询： 第一次加载页面时，不带任何游标条件。
-- 获取第一页数据，假设每页100条 SELECT id, user_name, created_at FROM orders WHERE status = 'completed' ORDER BY id ASC LIMIT 100;
从返回的结果中，取出最后一条记录的
id
值（例如是last_id_in_page
）。 -
加载下一页： 将上一步获取到的
last_id_in_page
作为下一页的起始游标。-- 获取下一页数据 SELECT id, user_name, created_at FROM orders WHERE status = 'completed' AND id > last_id_in_page ORDER BY id ASC LIMIT 100;
MySQL会直接利用
id
上的索引，从last_id_in_page
之后开始查找，效率极高。它只扫描需要返回的那些行，而不是从头开始扫描。
优点：
- 性能卓越： 几乎只读取需要的数据，极大地减少了磁盘I/O和CPU消耗。
- 稳定性高： 不受数据量增长的影响，性能曲线平稳。
局限性与考量：
- 仅支持“下一页/上一页”模式： 这种方式无法直接跳到“第50页”，因为你不知道第49页的最后一个ID是什么。它更适合无限滚动、瀑布流或者简单的“下一页”导航。
- 需要有序且唯一的游标字段： 如果你的表没有一个天然的、连续递增的唯一字段，可能需要额外引入一个，或者组合多个字段来模拟。
-
排序问题： 如果你的排序字段不是游标字段，或者排序字段不唯一，可能会出现问题。例如，按
created_at
排序，如果同一秒内有大量记录，created_at > 'last_time'
可能无法准确分页。这时，通常需要结合ID，形成复合条件：WHERE created_at >= 'last_time' AND id > 'last_id'
，或者WHERE (created_at = 'last_time' AND id > 'last_id') OR created_at > 'last_time'
。
结合业务场景，如何选择合适的分页策略？
选择分页策略，从来不是一个“一刀切”的问题，它得看你的业务场景到底需要什么。
场景一：瀑布流、无限滚动或简单“下一页”导航 这是最理想的情况，也是游标分页（ID或时间戳分页）大展身手的地方。用户通常只关心获取更多内容，而不是精确地跳到某一页。在这种情况下，ID分页的性能优势无可匹敌，因为它直接避免了大量无谓的数据扫描。
场景二：需要精确跳转到“第X页”的后台管理系统或报表 这场景就有点棘手了。用户可能需要输入页码直接跳转，或者看到总页数。
方案A：小数据量或可接受的延迟 如果你的“千万级”只是偶尔出现，或者用户对等待时间有一定容忍度，那么传统的
LIMIT OFFSET
可能还能勉强用。但要做好心理准备，当偏移量变大时，查询会变得非常慢。-
方案B：延迟关联（Deferred Join / Delayed Join） 当无法使用ID分页，又必须使用
OFFSET
时，可以考虑这种优化。它的思路是：先在子查询中利用索引找到需要的那部分数据的id
（或主键），然后用这些id
再去关联主表，获取完整的行数据。SELECT t.* FROM your_table t INNER JOIN ( SELECT id FROM your_table WHERE some_condition ORDER BY sort_column ASC LIMIT 1000000, 100 ) AS subquery ON t.id = subquery.id;这样做的好处是，子查询
SELECT id ...
因为只取id
，通常会走覆盖索引（如果sort_column
和id
都在一个索引里），或者至少避免了读取所有列的数据。主查询再根据少量id
去精确查找，减少了全表扫描的开销。这比直接SELECT * LIMIT OFFSET
要好，但本质上还是需要扫描offset + limit
个索引项。 方案C：缓存或预计算 对于那些不经常变动，但又需要频繁分页查询的报表数据，可以考虑将查询结果缓存到Redis、Memcached等内存数据库中，或者定期将查询结果预计算并存储到一个新的“快照表”中。这样，用户的查询直接命中缓存或快照表，速度飞快。但这种方案增加了系统的复杂性和数据一致性的挑战。
关于总页数或总记录数： 对于千万级数据，
SELECT COUNT(*)本身就是个灾难。
- 如果你不需要精确的总数，可以考虑近似值。例如，每隔一段时间更新一个缓存的总数，或者通过一些统计信息估算。
- 如果必须精确，并且数据变化不大，可以*缓存`COUNT()`的结果，或者考虑异步计算**并在前端展示“正在加载总数”的状态。
- 更激进一点，重新思考UI设计，是否真的需要总页数？很多产品，尤其是内容型产品，已经放弃了显示总页数，转而采用无限滚动。
没有银弹，每种方案都有其适用场景和局限。理解它们背后的原理，才能根据实际业务需求做出最合适的选择。
