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比等它“想明白”更可靠。
