ORDER BY 未走索引需先查执行计划并核对排序字段顺序；必须满足最左前缀原则且ASC/DESC方向一致，混合方向或非最左字段将触发filesort。
ORDER BY 没走索引？先看执行计划和排序字段顺序
MySQL 对 ORDER BY 使用索引有严格限制：必须满足最左前缀原则，且排序方向（ASC/DESC）需一致。如果查询中混合了 ASC 和 DESC，或排序字段不在联合索引最左侧，优化器大概率会放弃索引而走 filesort。
- 用
EXPLAIN SELECT ... ORDER BY查看Extra列是否含Using filesort - 联合索引
(a, b, c)可支持ORDER BY a, b或ORDER BY a, b, c（全 ASC 或全 DESC），但不支持ORDER BY a ASC, b DESC（8.0.12+ 支持，但需显式创建降序索引） - 如果只查少量字段，考虑覆盖索引：把
SELECT字段也加入索引末尾，避免回表
GROUP BY 为什么慢？本质是隐式排序 + 临时表
GROUP BY 默认会对分组字段做排序（除非加 ORDER BY NULL），且当结果集超出 tmp_table_size 或 max_heap_table_size 时，会从内存临时表退化为磁盘临时表，性能断崖下跌。
- 确认是否真需要排序：在语句末尾加
ORDER BY NULL可跳过隐式排序 - 检查
SHOW VARIABLES LIKE 'tmp_table_size'，若常出现Created_tmp_disk_tables增长，说明临时表频繁落盘 - 用
EXPLAIN观察type是否为ALL（全表扫描）；如是，优先给GROUP BY字段建索引 - 避免在
GROUP BY中使用函数或表达式，例如GROUP BY DATE(create_time)会导致索引失效
ORDER BY + GROUP BY 共存时的典型陷阱
当一条语句同时含 GROUP BY 和 ORDER BY，MySQL 会先分组再排序，若两者字段不一致，极易触发双重排序和临时表。更糟的是，某些版本（如 5.7）无法复用同一索引兼顾两者。
- 尽量让
GROUP BY和ORDER BY字段完全一致，例如都用user_id，避免GROUP BY user_id ORDER BY created_at - 如果业务允许，改用子查询分离逻辑：
SELECT * FROM (SELECT user_id, COUNT(*) cnt FROM logs GROUP BY user_id) t ORDER BY cnt DESC;
- 对高频聚合场景，考虑物化中间结果：用
CREATE TEMPORARY TABLE或定期写入汇总表，避开实时计算
索引设计要匹配实际访问模式，不是字段越多越好
给 ORDER BY 或 GROUP BY 单独建单列索引效果有限；真正有效的是按查询中 WHERE → GROUP BY → ORDER BY → SELECT 的顺序组合索引。但要注意字段选择性——低区分度字段（如 status 只有 0/1）放前面会大幅降低索引效率。
- 示例：查询
SELECT category, COUNT(*) FROM products WHERE deleted = 0 GROUP BY category ORDER BY COUNT(*) DESC，理想索引是(deleted, category)，而非(category)或(deleted, category, id) - 用
SELECT COUNT(DISTINCT column)/COUNT(*)估算区分度，低于 0.01 的字段慎作索引前导列 - 注意
NULL值处理：B-tree 索引中NULL被当作最小值统一存放，若字段大量为NULL，可能使范围查询失效
最常被忽略的一点：GROUP BY 在没有 WHERE 条件时，即使有索引，也可能因统计信息不准导致优化器误选全表扫描——此时手动加 FORCE INDEX 比等它“想明白”更可靠。
