安全分页需ORDER BY与LIMIT配合，且排序字段组合须唯一（如加主键兜底）；深分页用OFFSET性能差，应改用游标分页，基于上页末条记录的排序值进行WHERE过滤。
ORDER BY 和 LIMIT 必须一起用才能安全分页
单独 ORDER BY 不保证结果稳定，尤其在有重复排序字段值时（比如多个用户注册时间相同），mysql 可能每次返回不同行序。必须配合 LIMIT 且确保排序字段组合能唯一标识每行，否则 OFFSET 分页会跳过或重复数据。
- 推荐在
ORDER BY中加入主键（如id）兜底：例如ORDER BY created_at DESC, id DESC - 避免仅靠
ORDER BY name分页——名字重复太常见 -
LIMIT 20 OFFSET 40这类写法在深分页（如OFFSET超过 10 万）时性能急剧下降，因为 MySQL 仍要扫描前 40 行
用游标分页替代 OFFSET 避免性能雪崩
当列表需支持“下一页”且数据实时变动时，游标分页比 OFFSET 更可靠、更快。核心是记住上一页最后一条记录的排序字段值，下一次查询用 WHERE + 排序条件过滤。
- 假设按
created_at DESC, id DESC排序，第一页取最后一条为('2024-05-01 10:23:45', 12345) - 第二页查：
WHERE (created_at, id) - 注意括号内元组比较是 MySQL 原生支持的，无需拆成两个 AND 条件
- 游标分页无法直接跳转到第 100 页，但适合“加载更多”场景，且不受新插入/删除数据影响翻页错位
分页 SQL 中 count(*) 的代价常被低估
前端显示“共 123456 条”看似友好，但 select COUNT(*) FROM table WHERE ... 在大数据量 + 复杂 WHERE 条件下可能比主查询还慢，且结果很快过期。
- 如果业务允许，改用估算值：查
TABLE_ROWS（从information_schema.TABLES，仅 MyISAM 精确，InnoDB 是估算） - 或加缓存：对固定条件的列表，把总数缓存 5–10 分钟
- 更务实的做法是不显示总数，只提供“下一页”按钮，或显示“已加载 20 条，还有更多…”
- 切勿在分页接口里同时返回数据和精确总数——除非确认该 COUNT 已命中索引且执行时间
复合索引必须覆盖 ORDER BY + WHERE 字段
分页性能卡点往往不在 LIMIT，而在排序和过滤能否走索引。如果 ORDER BY a DESC, b DESC 但索引是 (a, c)，MySQL 就得回表排序，深分页时 I/O 直接拉满。
- 建索引前先看
EXPLaiN输出的type是否为range或ref，Extra是否含using filesort - WHERE 条件字段放索引前面，ORDER BY 字段紧随其后，例如：查询
WHERE status = 1 ORDER BY created_at DESC, id DESC→ 索引应为(status, created_at, id) - ASC/DESC 在 MySQL 8.0+ 支持混合方向索引，但 5.7 只支持全 ASC 或全 DESC；若用 5.7，统一用 DESC 更匹配常见时间倒序需求
SELECT id, title, created_at FROM article WHERE status = 1 AND (created_at, id) < ('2024-05-01 10:23:45', 12345) ORDER BY created_at DESC, id DESC LIMIT 20; 游标值本身容易被篡改或过期，服务端必须校验其格式和业务有效性，比如检查 created_at 是否在合理时间范围内，id 是否真实存在。