mysql执行order by未走索引时会强制创建内部临时表，关键依据是explain中extra出现using temporary；常见原因包括索引方向不匹配（如5.7不支持混合asc/desc）、排序字段未被联合索引覆盖、select *拖入大字段致临时表落盘，以及join中排序字段属非驱动表引发隐式物化。
ORDER BY字段没走索引，MySQL只能先取再排
MySQL执行ORDER BY时，如果无法直接利用索引的有序性输出结果，就必须把满足WHERE条件的数据全捞出来，在内存里排序——这个过程就强制触发内部临时表。关键判断依据是EXPLAIN中Extra列出现Using temporary。
- 常见错误：对
created_at DESC排序，但索引是(status, created_at ASC)，方向不一致 → 5.7及更早版本完全失效；8.0+才支持混合方向索引 - 更隐蔽的坑：WHERE用了
status = 'paid'，但ORDER BY是user_id，而索引没覆盖user_id→ 即使status走了索引，排序仍需临时表 - 别被
type=ref骗了：它只说明WHERE用了索引，不代表ORDER BY也走索引；必须看key字段是否和排序字段匹配
多字段排序顺序与索引定义不严格对齐
联合索引对ORDER BY生效的前提是字段顺序、方向、覆盖范围三者完全一致。哪怕只差一个字段或一个方向，优化器就会放弃索引排序，转而建临时表。
- 写法：
ORDER BY a ASC, b DESC→ 索引必须是(a, b)且MySQL ≥ 8.0；5.7建(a, b)也会退化 - 写法：
ORDER BY a, b, c→ 索引(a, b)不够，缺c字段 → 必然Using temporary - 写法：
WHERE a = 1 ORDER BY b, c→ 索引(a, c, b)无效，因为b不是前缀连续字段
SELECT * + ORDER BY 多带出大字段，撑爆内存临时表
SELECT *会把所有列（包括TEXT、BLOB）拖进排序流程，即使你只按id排序。一旦数据量稍大，就超出tmp_table_size和max_heap_table_size中较小的那个值，临时表立刻落盘，生成#sql_*磁盘文件。
- 查
Created_tmp_disk_tables持续上涨，基本就是这个原因 - 修复方式：明确写出需要的字段，避免
SELECT *；尤其要剔除大字段 - 别迷信
sort_buffer_size：它只管排序阶段，救不了临时表本身超限；真正该调的是tmp_table_size和max_heap_table_size，且必须设成相同值
ORDER BY 和 JOIN 顺序冲突导致隐式物化
当ORDER BY字段不属于驱动表（JOIN中最先访问的表），MySQL无法流式输出结果，只能先把右表结果集物化成临时表，再整体排序。这种情况在EXPLAIN里看不到明显索引失效，但Extra里一定有Using temporary。
- 典型场景：
SELECT o.* FROM orders o JOIN users u ON o.user_id = u.id ORDER BY u.name→u.name来自被驱动表，必然触发临时表 - 解法优先级：改写SQL让排序字段落在驱动表；其次补联合索引覆盖
JOIN + ORDER BY字段；最后才考虑调大内存参数 - ORM自动生成SQL时特别容易踩这个坑，比如Laravel的
with('user')->orderBy('users.name')，得手动用join重写
临时表本身不可怕，可怕的是它无声无息地落盘。很多问题表面看是慢查询，根子却在ORDER BY字段和索引之间那几毫秒的错位。
