MySQL分页首选LIMIT+OFFSET，需配合ORDER BY并校验OFFSET非负；大数据量时应改用基于排序字段的游标分页；避免使用ROW_NUMBER()等子查询方式，因其性能更差且无法利用early-termination优化。
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 值”。例如：
vue-store高仿小米商城
下载
本项目前后端分离，前端基于Vue+Vue-router+Vuex+Element-ui+Axios，参考小米商城实现。后端基于Node.js(Koa框架)+Mysql实现。前端包含了11个页面：首页、登录、注册、全部商品、商品详情页、关于我们、我的收藏、购物车、订单结算页面、我的订单以及错误处理页面。实现了商品的展示、商品分类查询、关键字搜索商品、商品详细信息展示、登录、注册、用户购物车、订单结算
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 更难排查。
