MySQL 分页用 LIMIT
和 OFFSET
最直接
绝大多数分页场景，靠
LIMIT+
OFFSET就能解决。语法是：
SELECT * FROM table LIMIT offset, row_count或
SELECT * FROM table LIMIT row_count OFFSET offset。前者更常用，也更直观。
比如查第 3 页、每页 10 条：
SELECT * FROM users LIMIT 20, 10（跳过前 20 条，取 10 条）。注意：这里的
offset是从 0 开始计数的，不是页码。 页码转 offset 要小心：第 N 页对应
offset = (N - 1) * page_size，别写成
N * page_size
OFFSET值很大时（比如 > 10 万），查询会明显变慢，因为 MySQL 仍需扫描并跳过前面所有行 如果表有主键且有序，用「游标分页」（基于上一页最后 ID）比
OFFSET更高效，尤其用于无限滚动
ORDER BY 必须加，否则分页结果不可靠
没有
ORDER BY的分页查询，每次执行返回的顺序可能不同，导致同一页数据重复或遗漏。MySQL 不保证无排序时的行返回顺序。
正确写法示例：
SELECT id, name FROM products ORDER BY id ASC LIMIT 10 OFFSET 20。推荐用主键或带索引的列排序，避免
ORDER BY RAND()这类无法利用索引的操作。 如果业务需要按时间倒序，优先用
created_at DESC并确保该字段有索引 复合排序要明确：比如
ORDER BY status ASC, updated_at DESC，避免因 NULL 或相同值引发顺序漂移 不要在分页 SQL 中动态拼接
ORDER BY字段名，容易引发 SQL 注入；应通过白名单校验字段合法性
大数据量下 LIMIT M,N
性能骤降的原因和应对
当
M很大（例如
LIMIT 1000000, 20），MySQL 实际执行是“读取前 1000020 行，丢弃前 1000000 行”，I/O 和 CPU 开销都集中在无效扫描上。 EXPLAIN 显示
rows值远大于实际返回行数，就是典型信号 用覆盖索引可缓解：例如只查
id，再用这些
id回表，比直接
SELECT *快得多 真正高并发、大数据量的分页（如后台管理查百万级日志），建议改用条件分页：记录上一页最大
id，下一页查
WHERE id > ? ORDER BY id LIMIT 20MyISAM 引擎下
LIMIT性能比 InnoDB 更差，不建议在新项目中使用 MyISAM
MySQL 8.0+ 支持窗口函数，但分页仍不推荐替代 LIMIT
虽然
ROW_NUMBER()可以实现逻辑分页，比如：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM users) t WHERE rn BETWEEN 21 AND 30，但这只是“模拟”，性能通常更差。
原因在于：窗口函数必须先计算全部行的序号，再过滤，无法提前终止。而
LIMIT是执行器层的物理限制，MySQL 可以边扫描边截断。 窗口函数适合做“组内排名”“累计统计”，不是为分页设计的 若必须用窗口（如配合复杂聚合后分页），务必加好
ORDER BY子句，否则
OVER()报错 低版本 MySQL（FUNCTION xxx does not exist
实际项目里，95% 的分页需求用好
LIMIT+ 索引 + 明确
ORDER BY就够了。真正卡住的往往不是语法，而是没意识到
OFFSET越大越慢，以及忘了给排序字段建索引。
