组合索引能消除using temporary和filesort，因b+树天然有序，当where等值条件匹配索引最左前缀且order by字段顺序、方向与索引完全一致时，mysql可直接按叶子节点顺序读取，无需额外排序或临时表；否则任一错位均导致索引失效。
直接建对顺序的联合索引，是消除 ORDER BY 引发的 Using temporary; Using filesort 最可靠方式；但索引字段顺序、是否覆盖查询列、WHERE 条件匹配程度，任何一个没对齐，就白建。
为什么组合索引能干掉临时表
MySQL 的 B+ 树索引天然有序。当 ORDER BY 字段顺序和索引定义完全一致（包括 ASC/DESC），且 WHERE 条件能命中索引最左前缀时，优化器就能按索引叶子节点顺序逐条读取——数据本来就是排好序的，根本不用建临时表、也不用额外排序。
此时 EXPLAIN 的 Extra 字段会显示 Using index 或空值，而不是 Using temporary; Using filesort。
常见错误现象：
- 查询是
WHERE status = 'active' ORDER BY create_time, id，却只建了(create_time)单列索引 → 仍触发临时表 - 建了
(create_time, id)，但查询写成ORDER BY id, create_time→ 不满足最左前缀，索引失效 - 索引是
(status ASC, create_time ASC)，但查询写ORDER BY create_time DESC→ MySQL 8.0+ 可能反向扫描，低版本或复杂条件大概率退化
组合索引字段顺序怎么排才不踩坑
核心就一条：WHERE 等值条件字段在前，ORDER BY 字段严格接在后面，且顺序、方向必须和 SQL 里一模一样。
比如这个查询：
SELECT id, user_id, amount FROM orders WHERE status = 'paid' AND shop_id = 1001 ORDER BY create_time DESC, id ASC;
对应索引必须是：
CREATE INDEX idx_orders_status_shop_time_id ON orders(status, shop_id, create_time DESC, id ASC);
不能漏掉 shop_id（它是等值条件），不能把 create_time 放前面（否则 WHERE 无法用全），也不能省略 DESC/ASC 声明（尤其当有混合方向时）。
容易忽略的点：
- 范围条件（如
shop_id > 1000）之后的字段，哪怕在索引里，也无法用于排序 —— 所以尽量把范围条件放最后 - 如果
WHERE里有IN，它算等值条件，可以放在排序字段前面；但OR通常破坏索引连续性，慎用
要不要把 SELECT 字段也塞进索引里
不是“要不要”，而是“不加就可能白优化”。只要 SELECT 的字段全在索引里（即构成覆盖索引），MySQL 就不用回主键聚簇索引查数据，自然避免额外 I/O 和潜在的临时表膨胀。
比如上面那个查询，如果只建了 (status, shop_id, create_time, id)，但表里 amount 没包含进去，那即使排序走索引，还得回表取 amount，而回表过程在大数据量下可能触发临时表重建。
所以更稳妥的写法是：
CREATE INDEX idx_orders_cover ON orders(status, shop_id, create_time DESC, id ASC, amount);
注意：amount 放最后，不影响排序逻辑，但能覆盖查询。不过字段越多，索引体积越大，写入开销越高——得权衡读多还是写多。
EXPLAIN 看什么才算真正生效
别只盯着 type 是不是 range 或 ref，重点看三处：
-
key字段：显示实际命中的索引名，确认没走错索引 -
Extra字段：必须没有Using temporary和Using filesort；出现Using index是加分项 -
rows字段：比没索引时显著减少，说明过滤有效；如果还是全表行数，可能是索引没被选中，或WHERE条件太弱
特别提醒：MySQL 优化器有时会“自作聪明”放弃你建的索引，改用全表扫描。这时候要加 FORCE INDEX 强制走索引，再对比性能。
最常被忽略的细节是：索引建完不等于问题消失，必须拿真实数据 + 真实查询跑 EXPLAIN 验证；很多线上慢查询，索引看着对，但因为统计信息过期、数据倾斜或隐式类型转换，照样走不了索引。
