MySQL索引排序要求ORDER BY字段为索引最左前缀且方向一致，否则触发Using filesort；深度分页应改用游标分页；索引设计优先满足ORDER BY而非WHERE；ORDER BY RAND()需避免。
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 触发磁盘临时表。检查每条慢查询的执行计划，比背技巧更重要。
