在开发数据量较大的应用时，我们经常需要遍历整个表进行数据处理，比如生成站点地图（sitemap）、导出数据、批量更新等。最常见的做法是使用 LIMIT offset, size 分页查询。然而，当 offset 变得很大时，查询会越来越慢，甚至导致超时或服务器负载飙升。本文将介绍一种简单却极其高效的方法——基于主键的游标查询（WHERE id > last_id），它能让你的数据遍历速度恒定，即使处理百万级数据也能轻松应对。
传统分页的痛点
假设我们有一张歌曲表 music_songs，主键为 song_id，我们需要导出所有歌曲的 URL 到 sitemap。传统分页写法：
SELECT song_id FROM music_songs ORDER BY song_id LIMIT 1000000, 1000;这条 SQL 在执行时，数据库需要先扫描并跳过前 100 万行，然后返回接下来的 1000 行。即使 song_id 有主键索引，MySQL 也会先读取 100 万行的索引项，再回表获取数据，当偏移量巨大时，这部分开销非常可观，而且随着页码增加，性能线性下降。
更糟糕的是，使用 OFFSET 会导致重复扫描：每次查询都要从第一行开始数，越往后越慢。在生成 600 万条数据的 sitemap 时，最初的几十万条还能较快返回，但越到后面，每一批都要等待几十秒甚至几分钟，整个导出过程可能需要几个小时。
游标查询的核心思想
游标查询利用主键自增的特性，每次只查询 id 大于上一次最大 id 的记录，从而避免“跳过”已读数据。它的基本形式是：
SELECT * FROM table WHERE id > last_id ORDER BY id LIMIT batch_size;每次查询后，将本批次最大的 id 作为下一轮的 last_id，循环直至没有数据返回。
这种方式的查询性能是恒定的，因为每次都是利用主键索引直接定位到 last_id 之后的位置，然后扫描 batch_size 条记录。无论数据总量多大，每批查询的时间几乎相同。
为什么游标查询这么快？
- 索引直接定位：
id > last_id可以迅速定位到索引中的起始位置，不需要扫描之前的记录。 - 顺序读取：由于数据在索引中是有序存储的，后续的
ORDER BY id只是顺序读取，非常高效。 - 固定扫描量：每批只扫描
batch_size条数据，不会随着数据总量增长而增加。
游标查询的适用场景
- 全表数据导出：如生成 sitemap、导出 CSV、备份数据等。
- 批量处理任务：对每一条数据执行某种操作（如 AI 生成文章、更新字段），且不需要跳跃式访问。
- 数据迁移：将数据从一个表复制到另一个表。
- 实时数据流处理：从数据库持续读取新数据（类似消息队列）。
游标查询的限制
- 必须基于单调递增的主键（或其它排序字段）才能保证顺序。如果主键不是单调递增，但业务中有时间戳字段等，也可以使用类似方法，但需要建立对应索引。
- 不能随机跳页：如果需要实现“跳到第 N 页”的用户界面，游标查询就不适合了，因为
last_id必须由上一页决定。此时仍应使用LIMIT offset, size，但可以考虑在业务中优化（如减少页数、使用缓存）。 - 注意排序字段的稳定性：如果排序字段存在重复值，必须确保排序唯一，否则可能丢失数据。通常主键是唯一且递增的，最为安全。
性能对比实测
在我处理 600 万条歌曲数据的 sitemap 生成时，使用传统 OFFSET 分页，生成到 100 多个 XML 文件就耗时数小时，且越往后越慢。改用游标查询后，整个过程在几秒内完成，每批查询稳定在毫秒级。性能差异惊人！
总结
游标查询（WHERE id > last_id）是一种简单而强大的优化技巧，尤其适合需要遍历整个表的数据处理场景。它摒弃了笨重的 OFFSET，利用主键索引的有序性，实现了恒定时间的分页。在实际开发中，当你需要“逐条处理所有数据”时，不妨试试这个方法，也许能给你带来意想不到的性能提升。
提示：如果查询中还需要其他过滤条件（如 status = 1），一定要在 (status, id) 上建立联合索引，以保证查询依然能高效定位。例如：
ALTER TABLE music_songs ADD INDEX idx_status_id (status, id);然后查询改为：
SELECT * FROM music_songs WHERE status = 1 AND id > last_id ORDER BY id LIMIT batch_size;这样既能过滤，又能利用索引有序性，性能同样出色。
暂无评论内容