mysql分页应使用limit (page-1)*size, size，注意offset从0开始且需校验参数；深分页性能差因逐行扫描，推荐游标分页（where+排序字段）替代。
MySQL 用 LIMIT 实现分页的正确写法
MySQL 分页靠 LIMIT，但不是简单加两个数字就完事。最常用的是 LIMIT offset, size 形式，比如查第 2 页、每页 10 条：LIMIT 10, 10（跳过前 10 条，取接下来 10 条）。
注意：第一个参数是偏移量（从 0 开始），不是页码。页码为 page 时，offset 应为 (page - 1) * size。直接写 LIMIT 2, 10 想查第 2 页？那是错的——它跳过前 2 条，不是前 2 页。
- 后端传参建议校验
page > 0且size在合理范围（如 1–100），避免LIMIT -5, 10或超大 offset 导致 SQL 报错或性能崩塌 - order by 必须显式指定，否则分页结果可能乱序——MySQL 不保证无排序时的行顺序
- 不要用
LIMIT 1000000, 20查深分页，MySQL 仍要扫描前 1000020 行，响应会明显变慢
深分页性能差，为什么 OFFSET 越大越慢
LIMIT offset, size 的底层逻辑是：MySQL 先定位到第 offset + 1 行，这需要逐行遍历前面所有记录（即使不返回）。当 offset 达到几十万，IO 和 CPU 开销陡增，查询可能从毫秒级变成秒级甚至超时。
典型现象：SELECT * FROM orders ORDER BY id DESC LIMIT 999990, 10 执行缓慢，而 LIMIT 0, 10 飞快。
- 根本原因：没有利用索引跳过前 N 行，而是“数着走”
- 优化方向不是调大 buffer，而是改用游标分页（cursor-based pagination）
- 如果必须用 offset，确保
ORDER BY字段有索引，且类型匹配（比如id是BIGINT，就别拿字符串去比较）
用 WHERE + 排序字段替代 LIMIT OFFSET 做游标分页
游标分页不依赖行号，而是记住上一页最后一条的排序值，下一页查“比它更小/更大的记录”。适用于按主键或时间戳分页，且数据写入相对稳定（无频繁插入打乱顺序）。
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
例如按 id 降序分页，第一页取最大 10 条：SELECT * FROM users ORDER BY id DESC LIMIT 10；假设最后一条 id = 12345，第二页就查：SELECT * FROM users WHERE id 。
- WHERE 条件必须和 ORDER BY 字段一致，且能命中索引（
EXPLAIN看type是否为range） - 如果排序字段不唯一（比如多个记录
created_at相同），需追加唯一字段（如id）做二级排序，避免漏数据或重复 - 前端不能跳页（比如直接输“第 100 页”），只能“下一页/上一页”，因为没存中间页的游标值
MySQL 8.0+ 的 ROW_NUMBER() 能否简化分页逻辑
可以，但不推荐用于常规分页。ROW_NUMBER() 是窗口函数，适合做“取排名前 N”或“按组分页”，但对全表分页并无性能优势——它仍需计算全部行的序号，再过滤，本质还是扫全表。
示例：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM users) t WHERE rn BETWEEN 11 AND 20。看似直观，实际执行计划里常出现 Using temporary; Using filesort，比带索引的 WHERE 游标还慢。
- ROW_NUMBER() 更适合一次性导出、报表类场景，而非在线 API 分页
- 若真要用，务必在
OVER()中的ORDER BY字段建索引，否则性能灾难 - 注意：MySQL 5.7 及更早版本不支持窗口函数，强行用会报错
FUNCTION xxx.ROW_NUMBER does not exist
游标分页的健壮性远高于 offset 分页，但要求业务接受“不可跳页”和“游标值需透传”的约束。OFFSET 看似简单，却是线上慢查询的高频诱因。
