MySQL 的 LIMIT
和 OFFSET
基本写法
MySQL 分页靠
LIMIT控制返回行数，
OFFSET控制跳过多少行。标准语法是：
LIMIT offset, row_count或
LIMIT row_count OFFSET offset。两种写法等价，但后者更易读，尤其在复杂查询中。
比如查第 2 页、每页 10 条（即跳过前 10 条）：
SELECT * FROM users ORDER BY id LIMIT 10 OFFSET 10;
注意：
OFFSET从 0 开始计数，所以第 1 页对应
OFFSET 0，不是 1。
为什么大偏移量（如 OFFSET 100000
）会变慢
MySQL 在执行
OFFSET N时，并不会“直接跳到第 N 行”，而是先扫描并丢弃前 N 行结果，再取后续数据。当
OFFSET很大时，即使只查 10 条，也可能要扫描上十万行，I/O 和 CPU 开销陡增。 表无主键或排序字段没索引 → 全表扫描 + 文件排序，性能雪崩
ORDER BY字段未建索引 → 强制使用
Using filesort即使有索引，若
WHERE条件过滤后仍需跳过大量匹配行，
OFFSET依然低效
替代方案：用游标分页（WHERE id > ? LIMIT 10
）
对有序、单调递增的字段（如自增
id或时间戳
created_at），用条件过滤代替
OFFSET是更高效的做法。它避免跳过中间行，走索引范围扫描即可。
例如，上一页最后一条记录
id = 12345，下一页应这样查：
SELECT * FROM users WHERE id > 12345 ORDER BY id LIMIT 10;
关键点：
必须保证ORDER BY字段和
WHERE条件字段一致且有索引 不能跳页（比如从第 1 页直接到第 100 页），只能逐页推进 如果排序字段可能重复（如多个记录同一天创建），需加第二排序字段去重，如
ORDER BY created_at, id
实际分页中容易忽略的细节
很多人只关注语法，却栽在边界和一致性上：
未加ORDER BY就用
LIMIT→ 结果顺序不确定，分页错乱 用
OFFSET实现“总页数”计算时，先
COUNT(*)再分页 → 高并发下数据变动会导致总数和分页结果不一致
LIMIT后面的数字是整数，不能是变量或表达式（除非用预处理语句或服务端拼接） 某些 ORM（如 Django 的
QuerySet）默认用
LIMIT/OFFSET，大数据量时需手动切到游标分页
真正棘手的不是怎么写分页，而是怎么让分页在数据持续写入、排序字段不唯一、需要跳转页码这些现实约束下依然可靠。
