limit offset, size在大数据量下变慢，是因为mysql必须扫描offset + size行后丢弃前offset行，导致i/o和cpu开销随offset增大而剧增；深度分页时易出现漏行、重复，且即使有索引也无法避免回表与全量排序。
为什么LIMIT offset, size在大数据量下越来越慢
MySQL执行LIMIT offset, size时，并不会跳过前offset条记录，而是先扫描offset + size条，再丢弃前面的offset条。比如LIMIT 100000, 10，实际要读取100010行——哪怕只返回10条。数据越往后，扫描越多，I/O和CPU开销直线上升。
更麻烦的是，如果ORDER BY字段没走索引，或者排序字段存在大量重复值（导致排序不稳定），分页结果还可能漏行或重复。
- 偏移量超过10万后，查询耗时通常从毫秒级跳到秒级
-
EXPLAIN里看到rows远大于size，就是典型征兆 - 即使加了索引，
OFFSET大时仍需回表+排序，无法规避扫描成本
用ROW_NUMBER()实现确定性分页的写法
窗口函数不依赖物理偏移，而是为逻辑排序后的每一行分配唯一序号，适合需要稳定、可复现分页的场景（比如后台导出、审计日志）。
核心结构是CTE + 外层过滤：
WITH ranked AS (
SELECT id, name, amount,
ROW_NUMBER() OVER (ORDER BY amount DESC, id ASC) AS rn
FROM sales
WHERE status = 'done'
)
SELECT id, name, amount
FROM ranked
WHERE rn BETWEEN 21 AND 30;
-
ROW_NUMBER()必须配合OVER(ORDER BY ...)，且ORDER BY里建议包含主键（如id ASC）来打破并列，保证结果稳定 - 不能直接
WHERE rn > 20 LIMIT 10——MySQL不支持在窗口函数同级引用别名，必须套一层子查询或CTE - 如果分页条件含动态参数（如页码
$page），需计算BETWEEN ($page-1)*10+1 AND $page*10，注意整数溢出风险
ROW_NUMBER()分页 vs LIMIT分页：什么时候该换
不是所有场景都适合窗口函数。关键看你的瓶颈在哪、是否接受额外开销。
- 数据量小（LIMIT offset, size，简单高效
- 需要按复杂逻辑排序（如“按部门销售额总和降序，同部门内按员工姓名升序”）→
ROW_NUMBER()天然支持PARTITION BY+ 多级ORDER BY，LIMIT做不到 - 实时性要求高、表频繁写入 →
ROW_NUMBER()基于快照计算，两次查询间若数据变更，rn会变，但分页边界不会漂移；而LIMIT可能因新插入/删除导致跳页或重复 - 内存受限（如小规格RDS）→
ROW_NUMBER()需缓存整个中间结果集排序，OOM风险比LIMIT高得多
容易被忽略的性能陷阱
用了ROW_NUMBER()不代表自动变快。很多团队踩坑后才发现问题不在语法，而在执行路径。
- 没加
WHERE过滤就套CTE：先算全表ROW_NUMBER()再过滤，等于把压力全留给窗口函数。务必把WHERE条件写在CTE内部 - 排序字段无索引：
ROW_NUMBER() OVER (ORDER BY unindexed_col)会触发全表排序，比LIMIT还慢 - 误以为能替代游标分页：窗口函数分页仍是“全量排序+范围裁剪”，对千万级表仍可能超时；真要高性能，还是得用
WHERE id > last_id ORDER BY id LIMIT 10这类游标方案 -
EXPLAIN ANALYZE里看到Using filesort且rows_examined巨大，说明排序没走索引，得立刻补
窗口函数是工具，不是银弹。它解决的是“逻辑分页稳定性”和“复杂排序下分页”的问题，而不是单纯替换LIMIT来提速。真正的大数据分页，往往要组合索引、游标、延迟关联，再辅以ROW_NUMBER()做兜底校验。
