MySQL 分页查询用 LIMIT + OFFSET 最直接
绝大多数场景下，
LIMIT和
OFFSET是 MySQL 实现分页的唯一实用方式。它语法简单、语义清晰，不需要额外函数或子查询（除非有特殊需求）。
常见写法：
SELECT * FROM users ORDER BY id DESC LIMIT 20 OFFSET 40表示跳过前 40 条，取接下来的 20 条——即第 3 页（每页 20 条）。
OFFSET值 =
(page_no - 1) * page_size，务必校验非负整数，否则会报错或返回空结果 必须配合
ORDER BY使用，否则分页结果不可预测（InnoDB 行存储无天然顺序） 当
OFFSET很大（如 > 10 万），性能会明显下降，因为 MySQL 仍需扫描并跳过前面所有行
大数据量下 OFFSET 性能差？改用游标分页（Cursor-based Pagination）
当用户翻到第 500 页（
OFFSET 99980）时，
LIMIT ... OFFSET会变慢甚至拖垮数据库。这时应放弃“页码”概念，改用基于排序字段的游标分页。
核心思路：不记“第几页”，只记“上一页最后一条的
id或
created_at值”。例如：
SELECT * FROM orders WHERE created_at < '2024-05-01 10:23:45' ORDER BY created_at DESC LIMIT 20;要求排序字段（如
created_at）有索引，且值尽量唯一；若可能重复，需补充主键（如
ORDER BY created_at DESC, id DESC）避免漏/重数据 前端需保存上一页末尾记录的排序字段值，不能靠页码计算
OFFSET无法直接跳转任意页（比如从第 1 页跳到第 100 页），但符合主流 App/列表滚动加载的实际使用路径
为什么不要用子查询模拟分页（如 SELECT * FROM (SELECT ..., ROW_NUMBER() OVER(...) AS rn) t WHERE rn BETWEEN x AND y）
MySQL 8.0+ 虽支持
ROW_NUMBER()，但用它做分页是典型反模式。 即使加了
ORDER BY，子查询中
ROW_NUMBER()仍需全表排序并编号，性能比
LIMIT OFFSET更差 无法利用
LIMIT的 early-termination 优化（MySQL 在找到足够行后会提前停止） 语句更长、可读性差，且在低版本 MySQL（ 除非你同时需要行号展示（如“第 1 名”“第 2 名”），否则纯分页场景完全没必要引入窗口函数
实际项目里容易被忽略的边界问题
分页不是写对 SQL 就完事，业务逻辑层常埋雷：
总数统计和分页查询没共用相同WHERE条件，导致“共 105 条，每页 20 条，但第 6 页查不到数据” 前端传入
page=0或
size=-5，后端未校验就拼进 SQL，触发
OFFSET -5报错或越界 排序字段存在 NULL 值，且未指定
ORDER BY col DESC NULLS LAST（MySQL 不支持
NULLS LAST，需用
ORDER BY IF(col IS NULL, 1, 0), col DESC模拟） 缓存分页结果时，没把
WHERE条件、排序字段、
page_size全部纳入 key，导致不同筛选条件共用同一缓存
分页真正的复杂点不在 SQL 写法，而在条件一致性、参数安全、空结果处理和缓存粒度——这些地方出错，比写错
LIMIT更难排查。
