MySQL分页首选LIMIT+OFFSET，但大数据量时性能差；应加ORDER BY确保稳定性，推荐游标分页或条件分页优化；窗口函数不适用于分页。
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 20 - MyISAM 引擎下
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 越大越慢，以及忘了给排序字段建索引。
