联合索引列顺序必须严格从左到右匹配where条件，否则索引失效；order by需与索引顺序一致且不被范围查询截断；in/or慎用，优先union all分拆；索引设计应以查询实际条件、排序、覆盖需求为准，而非仅看字段区分度。
联合索引列顺序错，WHERE 条件直接“失效”
MySQL 的联合索引是 B+Tree 结构，数据按索引定义的**严格从左到右顺序排序**。一旦 WHERE 中没用上最左列，后续所有列都白搭——不是慢一点，而是根本用不上这个索引。
-
INDEX (a, b, c)可以加速WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b = 2 AND c = 3 - 但
WHERE b = 2或WHERE b = 2 AND c = 3会退化为全表扫描（type: ALL） - 哪怕你写了
WHERE c = 3 AND a = 1，优化器也能重排条件顺序匹配索引——前提是a在索引最左；如果索引是(c, a, b)，那a = 1单独出现就完全命中不了
ORDER BY 不走索引，额外触发 filesort
当查询带 ORDER BY 时，如果排序字段顺序和索引列顺序不一致，或者中间被范围查询（如 >、BETWEEN、LIKE 'abc%'）截断，MySQL 就无法利用索引天然有序的特性，只能回表后在内存或磁盘做二次排序（Extra: Using filesort）。
- 索引
(category_id, article_id)能完美支持WHERE category_id = 11 ORDER BY article_id DESC - 但如果索引是
(article_id, category_id)，即使category_id有等值条件，ORDER BY article_id也无法复用——因为article_id是第一列，但 WHERE 没过滤它，B+Tree 根本不知道从哪段开始扫 - 更隐蔽的是：索引
(a, b)支持ORDER BY a, b，但不支持ORDER BY b, a；也不支持WHERE a = 1 ORDER BY b DESC同时ORDER BY a ASC（方向混用）
IN / OR 查询性能断崖式下跌
很多人以为 WHERE col IN (1,2,3) 和 WHERE col = 1 OR col = 2 OR col = 3 是等价的，其实 MySQL 对后者几乎总是放弃使用索引（尤其复合索引中 col 不是最左列时），直接走全表扫描。
- 错误示范：
INDEX (status, created_at)+WHERE status IN ('draft','published') ORDER BY created_at DESC→ 很可能type: index全索引扫描，rows高达几十万 - 正确解法：改用
UNION ALL分拆，让每个子查询都能精准命中索引前缀：(SELECT * FROM t WHERE status = 'draft' ORDER BY created_at DESC LIMIT 10)<br>UNION ALL<br>(SELECT * FROM t WHERE status = 'published' ORDER BY created_at DESC LIMIT 10)<br>ORDER BY created_at DESC LIMIT 10
- 注意：
UNION会去重并临时排序，必须用UNION ALL；外层ORDER BY不可省，否则结果顺序无保证
别迷信“高区分度字段放最左”的经验法则
很多资料说“把选择性最高的列放前面”，这在纯等值查询（WHERE a = ? AND b = ?）下有一定道理，但现实远比这复杂——排序、分组、范围查询、覆盖索引需求，往往比单字段基数更重要。
- 比如用户查
WHERE city_id = 3205 ORDER BY quality DESC，即使quality基数（7549）比city_id（12942）低，索引(city_id, quality)仍比(quality, city_id)快一个数量级，因为它能同时满足过滤+排序 - 再比如要覆盖查询
SELECT name, email FROM user WHERE dept = ?，最优索引可能是(dept, name, email)——dept区分度不高也没关系，关键是把 SELECT 列全包进去，避免回表 - 真正该优先排的，是查询中**必然出现且不可跳过的最左条件列**，而不是“理论上唯一值最多”的那个
索引列顺序不是靠直觉或教条决定的，得盯着 EXPLAIN 的 key、key_len、rows、Extra 四项看——尤其是 key_len 是否随条件增加而变长，Extra 里有没有 Using where; Using index 这种理想组合。线上慢查不分析执行计划就调索引，跟蒙眼换轮胎差不多。
