MySQL 中 LIMIT
是在 WHERE、ORDER BY 之后执行的
很多人误以为
LIMIT会“提前截断”数据来提升性能，其实它是在整个查询逻辑处理完后才生效的。具体顺序是：
WHERE过滤 →
GROUP BY分组 →
HAVING筛选 →
SELECT投影 →
ORDER BY排序 → 最后才是
LIMIT取行。这意味着即使你只想要前 10 行，MySQL 仍可能扫描并排序全部匹配结果（尤其没走索引时）。
常见错误现象：
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 10在
status无索引、
created_at也未被联合覆盖时，会全表扫描 + 文件排序，再丢弃 99.9% 的行。 确认是否命中索引：用
EXPLAIN查看
key和
Extra字段，重点看有没有
Using filesort或
Using temporary如果
ORDER BY字段和
WHERE条件字段不同，考虑创建联合索引，例如
(status, created_at)
LIMIT后带偏移量（如
LIMIT 10000, 10）会导致 MySQL 跳过前 10000 行——这些行仍要被读取、排序、丢弃，性能陡降
分页场景下 LIMIT offset, size
的性能陷阱
传统
LIMIT 10000, 20分页在大数据集上非常危险：MySQL 必须定位到第 10001 行，意味着它得按排序顺序“数”够 10000 行，哪怕只返回 20 行。offset 越大，越接近全量扫描成本。
典型表现：第 1 页很快，第 500 页响应时间飙升，慢查询日志里反复出现同一类语句。
避免深分页：用游标分页（cursor-based pagination），基于上一页最后一条记录的排序字段值继续查，例如WHERE created_at如果必须用 offset，确保
ORDER BY字段有高选择性索引，且尽量让
WHERE条件大幅缩小结果集 注意：主键自增不等于排序稳定，若业务允许按
id分页，
WHERE id > ? ORDER BY id LIMIT 20比
LIMIT 10000, 20快一个数量级
MySQL 8.0+ 的窗口函数能否替代 LIMIT
分页？
不能直接替代。像
ROW_NUMBER() OVER (ORDER BY ...)生成序号后过滤，本质仍是先算出全部序号（即全量排序），再
WHERE rn BETWEEN 10001 AND 10020，性能通常比原生
LIMIT更差——因为多了临时表和额外计算开销。
除非你已经在用窗口函数做其他聚合/排名，顺带分页；否则为分页而加
ROW_NUMBER()是典型的“杀鸡用牛刀”。 验证方式：对比
EXPLAIN FORMAT=TREE输出，窗口函数分页必然含
Window function节点和
Materialize步骤 例外场景：极小结果集（ 注意：MySQL 5.7 不支持窗口函数，强行迁移需评估版本兼容性
LIMIT
对执行计划和索引选择的影响
LIMIT本身不会改变索引选择逻辑，但优化器会根据它感知“用户只要少量结果”，从而在某些场景下倾向使用更窄的索引（比如只覆盖
WHERE条件字段，而非包含
ORDER BY字段的联合索引）——这反而导致回表+排序，拖慢整体速度。
例如：表有索引
idx_status（仅
status）和
idx_status_created（
status, created_at），当执行
LIMIT 10时，优化器可能选前者，认为“反正只取 10 行，回表也快”，结果却触发
Using filesort。 强制指定索引：用
FORCE INDEX(idx_status_created)告诉优化器走覆盖索引 检查
rows和
filtered：在
EXPLAIN中若
rows很大但
filtered很低，说明
WHERE条件选择性差，
LIMIT救不了根本问题 注意：MySQL 8.0.20+ 引入了
limit_query_hints（如
/*+ LIMIT_ROWS(10) */），但目前仅影响部分内部估算，不改变物理执行路径
分页不是加个
LIMIT就万事大吉的事，真正卡住性能的往往是排序字段没索引、条件字段区分度低、或者 offset 值已经大到让 MySQL “数着走”——这些细节在慢查询日志和
EXPLAIN里都藏得挺深。
