SQL排序慢查询主因是未建索引导致FileSort；需用EXPLAIN查Extra列是否含“Using filesort”，并按WHERE先、ORDER BY后的原则建联合索引，再实测验证优化效果。
SQL查询中对未建索引的字段进行排序，是导致慢查询最常见的原因之一。数据库在执行 ORDER BY 时，若无法利用索引完成排序，就会触发 FileSort（文件排序），大量依赖磁盘临时空间和内存排序，显著拖慢响应速度。
如何快速识别排序字段无索引？
核心方法是查看执行计划（EXPLAIN）中的 Extra 列：
- 出现
Using filesort：明确表示 MySQL 无法用索引完成排序，必须额外排序 - 即使
type是ref或range，只要 Extra 含 filesort，排序仍低效 - 注意：如果
ORDER BY字段与WHERE条件字段共同构成联合索引的最左前缀，且顺序匹配，才可能避免 filesort
什么样的索引能支持高效排序？
关键不是“有没有索引”，而是索引结构是否满足排序需求：
-
单字段排序：直接在该字段上建普通索引即可（如
CREATE INDEX idx_status ON orders(status);） -
多条件查询 + 排序：优先建立联合索引，遵循 WHERE 先于 ORDER BY 原则
例如：SELECT * FROM orders WHERE shop_id = 100 ORDER BY created_at DESC;
应建：CREATE INDEX idx_shop_created ON orders(shop_id, created_at); -
覆盖排序：若排序字段类型为
TEXT或BLOB，无法直接建索引，需改用前缀索引或转换字段类型
常见踩坑场景与规避方式
很多优化失败，是因为忽略了隐式约束和数据特征：
-
ASC/DESC 混用：MySQL 8.0 之前不支持混合升序/降序联合索引；例如
ORDER BY a ASC, b DESC在老版本中仍会 filesort -
函数或表达式排序：如
ORDER BY UPPER(name)、ORDER BY DATE(created_at)，无法使用普通索引，需建函数索引（MySQL 8.0+）或冗余计算列索引 -
NULL 值干扰：若排序字段允许 NULL，而索引未显式处理（如未设
NOT NULL），部分场景下优化器可能弃用索引 -
数据倾斜严重：比如
status IN ('pending', 'done')占比 99%，即使有索引，优化器也可能认为全表扫描更快，需结合FORCE INDEX验证或调整统计信息
验证优化是否生效
不要只看执行计划，要实测效果：
- 用
EXPLAIN FORMAT=JSON查看using_filesort是否消失，以及using_index是否为 true - 开启慢查询日志，对比优化前后
Rows_examined和Query_time - 对高并发排序查询，观察
Sort_merge_passes状态变量是否下降（反映磁盘归并次数减少）
不复杂但容易忽略：排序性能问题往往藏在看似简单的 ORDER BY 后面，定位靠 EXPLAIN，解决靠索引设计，验证靠真实指标。
