ORDER BY 或 GROUP BY 无法利用索引排序时会触发临时表（Using temporary），关键在于索引列顺序、方向匹配、覆盖性及WHERE等值前置；MySQL 8.0+降序索引和函数索引可有效解决混合排序与表达式排序的临时表问题。
ORDER BY 用索引失效导致临时表
MySQL 在执行 ORDER BY 时，如果无法利用索引完成排序，就会创建内部临时表（Using temporary），严重拖慢查询。关键不是“有没有索引”，而是索引列顺序、是否覆盖、是否混用 ASC/DESC。
常见错误现象：EXPLAIN 输出中出现 Using filesort 或 Using temporary；查询在数据量增大后突然变慢。
- 复合索引必须严格匹配
ORDER BY的列顺序和方向，比如索引是(a, b DESC)，那ORDER BY a ASC, b DESC可走索引，但ORDER BY a DESC, b DESC就不行（首列方向不一致） - WHERE 条件中的等值列必须放在索引最左侧，才能让后续列用于排序。例如查询
WHERE status = 'active' ORDER BY created_at，索引应建为(status, created_at)，而非单独created_at - 如果
SELECT中有非索引列，且没用到覆盖索引，MySQL 可能仍需回表，但至少避免了临时表；若用了SELECT *且索引不覆盖，优化器有时反而放弃索引排序
GROUP BY 和 DISTINCT 触发临时表的典型场景
GROUP BY 和 DISTINCT 默认都会触发临时表，除非满足“索引完全覆盖 + 顺序匹配”两个硬条件。很多人以为加了索引就万事大吉，其实漏掉了隐式排序要求。
使用场景：统计报表、去重列表、分组聚合（如 COUNT(*), SUM(price)）
- MySQL 5.7+ 对
GROUP BY默认强制排序，即使你加了ORDER BY NULL，也要确保索引能同时满足分组和（可选）排序需求 - 索引列顺序必须和
GROUP BY列完全一致，且不能跳过前导列。例如GROUP BY region, category，索引(region, category, sales)有效；但(category, region)无效 - 如果语句里有
HAVING过滤聚合结果，它发生在临时表之后，无法推动索引优化；想绕过，得把过滤逻辑前置到 WHERE（比如先筛出高价值用户再分组）
联合索引设计中容易被忽略的覆盖与冗余问题
为了消除临时表而堆砌索引，反而引发写放大、内存占用高、优化器选错索引等问题。核心不是“多建索引”，而是“建对索引”。
参数差异：key_len 在 EXPLAIN 中暴露出实际用了索引的几列；Extra 字段是否含 Using index 表示是否覆盖。
- 确认是否覆盖：执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...，看Extra是否有Using index。没有？说明要回表，哪怕没临时表，I/O 成本也不低 - 避免冗余索引：比如已有
(a, b, c)，再建(a, b)就是冗余；但(a, c)可能有用（取决于查询模式），别盲目删 - 注意隐式类型转换：
user_id是INT，但 WHERE 里写了WHERE user_id = '123'（字符串），索引失效，排序/分组全退化成临时表
MySQL 8.0+ 的降序索引与函数索引实战价值
旧版本 MySQL 不支持真正的降序索引，只能靠升序索引“假装支持”，限制极多。8.0+ 的 DESC 显式声明和函数索引，才真正打通排序优化的最后一环。
性能影响：降序索引能让 ORDER BY a DESC, b ASC 这类混合方向排序直接走索引；函数索引则让 ORDER BY UPPER(name) 这类操作免于临时表。
- 建降序索引要显式写
CREATE INDEX idx ON t (a DESC, b ASC)，只写(a, b)在 8.0 下仍是升序，不解决DESC排序问题 - 函数索引必须用表达式建：比如
CREATE INDEX idx_name_upper ON t ((UPPER(name)))，括号不能少；且查询中ORDER BY UPPER(name)必须字面一致，不能写成ORDER BY upper(name)（大小写敏感） - 函数索引不支持
TEXT/BLOB全字段，需要加长度限制，例如((SUBSTR(content, 1, 100)))，否则建索引失败
临时表不是洪水猛兽，但它是性能拐点的明确信号。真正难的不是加索引，是读懂 EXPLAIN 里那一行 Extra 字段背后的真实执行路径——尤其是 Using temporary; Using filesort 同时出现时，说明排序和分组双双失控，这时候光调索引顺序已经不够，得回头检查查询结构本身是否合理。
