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 filesortWHERE 条件字段放索引前面，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是否真实存在。
