根本原因是b+树的字典序物理结构决定的：联合索引(a,b,c)中，c仅在a和b都完全相等的子块内有序；一旦b出现范围查询（如b>10），对应多个b值子块，c全局无序，无法二分查找，故第三列失效。
组合索引为什么只用到前两列，第三列完全失效？
根本原因在于最左前缀原则 + 范围查询截断。联合索引 (a, b, c) 是一棵按三元组排序的 B+ 树，数据先按 a 排，a 相同再按 b 排，b 相同才按 c 排。一旦中间出现范围条件（如 b > 10 或 b LIKE 'x%'），优化器就无法继续用 c 做有序查找——因为 c 在 b 的每个“子区间”内并不有序。
验证方法很简单：执行 EXPLAIN，看 key_len 值。比如 key_len = 8（假设 a 是 INT、b 是 VARCHAR(10)），说明只用了前两列；若 key_len = 4，那只有 a 生效。
- WHERE
a = 1 AND b > 10 AND c = 5→c不参与索引查找，仅用于回表后过滤 - WHERE
a = 1 AND c = 5→b缺失，c完全不可用，type很可能变成ALL - WHERE
b = 2 AND c = 3→ 没有a，整个索引不命中
如何让第三列也参与索引查找？
关键不是“强制让它用”，而是重构查询模式或索引结构，让 c 能落在连续有序段里。最直接的方式是把 c 放到范围列之后，或者改等值为范围。
- 如果业务允许，把条件改成
a = 1 AND c = 5 AND b BETWEEN 10 AND 20→ 仍只用到a和c？不行，c还是中间跳过b，依然无效 - 正确做法：调整索引顺序为
(a, c, b)，再查a = 1 AND c = 5 AND b > 10→ 此时b成为范围列，a和c都是等值，全部命中 - 或者，如果
c查询频率高且区分度好，考虑单独建索引(a, c)，但需权衡写入开销和冗余
注意：LIKE 'abc%' 属于范围查询，它会截断后续列；而 LIKE 'abc'（无通配符）是等值，不会截断。
EXPLAIN 中 key 显示索引名但 rows 很大，是不是部分命中？
是，但这不等于“有效命中”。key 非 NULL 只说明优化器选了这个索引，rows 大说明它预估要扫描大量索引项——可能因为 c 列选择性极低（如 status 只有 0/1），或数据倾斜严重（90% 的 a = 1 记录中 c = 5 占绝大多数）。
- 查
SHOW INDEX FROM table_name看Cardinality，对比字段实际唯一值比例 - 用
SELECT COUNT(DISTINCT c) / COUNT(*) FROM table_name算选择性，低于 0.01 就别指望靠它过滤 - 如果
c本就不该承担过滤职责，就别把它硬塞进 WHERE，改用应用层或覆盖索引减少回表
哪些写法会让组合索引“看似命中实则白搭”？
这类问题最隐蔽：SQL 看似合规，但优化器一算成本，直接放弃索引。常见诱因包括隐式转换、函数包裹、OR 混合索引与非索引列。
-
WHERE a = '1' AND b = 2→ 若a是 INT 类型，字符串'1'触发隐式转换，key可能为 NULL -
WHERE UPPER(c) = 'ABC'→ 函数操作使c列索引完全失效 -
WHERE a = 1 OR c = 5→ 若只有(a, b, c)索引，没有单独c索引，优化器大概率走全表扫描 -
SELECT *配合WHERE a = 1 AND b = 2→ 若c不在索引里，就要回表取整行，当表大、IO 紧张时，优化器宁愿扫全表
真正决定“是否值得走索引”的，从来不是语法对不对，而是优化器手里的统计信息和成本模型。别只盯着 key 是否非空，rows 和 Extra（比如 Using filesort）才是更真实的信号。
