ORDER BY 字段必须是索引最左前缀才能走索引排序
MySQL 只有在
ORDER BY的字段顺序和索引定义完全匹配（或为最左前缀）时，才能利用索引完成排序，避免
Using filesort。否则即使 WHERE 条件走了索引，排序仍会触发临时文件排序，性能陡降。 假设有复合索引
INDEX idx_status_created (status, created_at)，则
WHERE status = 1 ORDER BY created_at可走索引排序；但
WHERE status = 1 ORDER BY id不行，
id不在索引中
ORDER BY created_at DESC, status ASC也不行——方向不一致且顺序错位，MySQL 8.0+ 虽支持混合方向索引，但需显式创建如
INDEX(... ASC, ... DESC)用
EXPLAIN看
Extra列：出现
Using index; Using filesort表示用了覆盖索引但没躲开排序；只有
Using index才表示排序也由索引完成
LIMIT 配合索引排序时，避免“深度分页”陷阱
当写
ORDER BY created_at LIMIT 10000, 20，MySQL 仍要定位前 10000 行再取 20 行，导致越往后越慢。这不是 LIMIT 本身的问题，而是排序 + 偏移的组合代价高。 改用游标分页（cursor-based pagination）：记录上一页最后一条的
created_at值，下一页查
WHERE created_at > '2024-01-01 10:00:00' ORDER BY created_at LIMIT 20如果必须用 offset，确保
ORDER BY字段有高选择性且索引覆盖，否则优化器可能放弃索引而走全表扫描 注意：InnoDB 的聚簇索引主键顺序会影响排序效率；若按非主键排序且无合适索引，即使加了 LIMIT，执行计划仍可能显示
rows极大（只是提前终止）
WHERE + ORDER BY + LIMIT 组合下，索引设计优先满足排序而非过滤
当过滤条件和排序字段都可用索引时，索引字段顺序决定优化效果。MySQL 更倾向复用排序索引做过滤，而不是反过来。
场景：高频查询WHERE category = ? ORDER BY score DESC LIMIT 10。建索引应为
INDEX idx_category_score (category, score DESC)，而非
(score DESC, category)—— 后者无法高效过滤
category若
category区分度极低（如只有 3 个值），而
score分布广，则优先保证
score在前：但此时需配合
WHERE score BETWEEN ? AND ?限定范围，否则仍可能扫大量行 覆盖索引能进一步减少回表：比如查询还带
SELECT id, title, score，就把这些字段加到索引末尾，变成
INDEX(..., id, title, score)
ORDER BY RAND() 和 LIMIT 是隐式全表扫描杀手
ORDER BY RAND() LIMIT N看似简洁，实则对性能毁灭性打击：MySQL 必须给每一行计算随机数、排序、再取前 N 行，无法使用任何索引。 替代方案一（小表）：先
SELECT COUNT(*)得总数
C，应用层生成 N 个
[0, C)范围内的随机整数，再用
SELECT ... LIMIT 1 OFFSET ?拉取（注意
OFFSET仍慢，仅适用于 N 小、C 不大） 替代方案二（大表）：用主键随机抽样，例如
SELECT * FROM t WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) LIMIT 1，重复多次并去重（精度换速度） 绝对不要在生产环境对万级以上数据行执行
ORDER BY RAND()，
EXPLAIN显示的
rows通常是全表行数，且
Extra里必有
Using temporary; Using filesort
真正卡住性能的往往不是单个关键词，而是 ORDER BY 和 LIMIT 在没有对齐索引结构时产生的隐式代价——比如你以为加了索引就安全了，结果 EXPLAIN 里 still shows Using filesort，或者 LIMIT 10000 触发磁盘临时表。检查每条慢查询的执行计划，比背技巧更重要。
