为什么 EXPLAIN 显示 type=ALL 就基本等于索引失效
MySQL 用 EXPLAIN 查执行计划时，如果 type 列是 ALL，说明走了全表扫描——哪怕你加了索引，也没被用上。这不是“可能没用”，而是明确没走索引路径。
常见诱因包括：查询条件用了函数、隐式类型转换、OR 连接非索引字段、LIKE 开头带通配符（如 '%abc'）。
-
WHERE UPPER(name) = 'ABC'→ 函数包裹字段，索引失效；应改写为name字段统一存大写 + 直接等值匹配 -
WHERE user_id = 123，但user_id是VARCHAR类型，传入的是数字123→ 隐式转换触发全表扫描；必须保证类型一致，传'123' -
WHERE status = 1 OR create_time > '2024-01-01'→ 若只有status有索引，OR后半部分无索引，整条WHERE常常弃用索引；拆成UNION或补全复合索引更稳
复合索引最常踩的坑：WHERE 条件没按最左前缀顺序写
比如建了复合索引 INDEX idx_a_b_c (a, b, c)，只有满足「连续从左开始」的字段才能命中索引。不是“包含 a 就行”，而是 a 必须出现，且 b、c 要在 a 存在的前提下按序出现。
-
WHERE a = 1 AND c = 3→ 只能用上a，c无法跳过b使用索引 -
WHERE b = 2 AND c = 3→a缺失，整个索引完全失效 -
WHERE a = 1 AND b > 10 AND c = 5→a和b有效，c在b是范围查询时失效（范围之后的列不参与索引查找）
验证方法很简单：EXPLAIN 看 key_len。对 INT 字段，单列索引 key_len 通常是 5（含 null 标志位），复合索引中若 key_len = 5，说明只用了第一列。
ORDER BY 和 GROUP BY 不走索引？先看是否复用同一索引的有序性
MySQL 能利用索引的物理排序顺序避免额外排序（Using filesort），但前提是 ORDER BY 字段顺序和索引定义顺序严格一致，且没有混合 ASC/DESC（8.0+ 支持混合，但老版本不行），也不能有不在索引中的字段参与排序。
-
INDEX idx_created_user (created_at, user_id)，但查询是ORDER BY user_id, created_at→ 顺序错，必然Using filesort -
ORDER BY created_at DESC, user_id ASC→ 混合方向，5.7 及更早版本无法利用该索引排序 -
SELECT * FROM t ORDER BY created_at LIMIT 10→ 如果created_at有索引，这个可以走索引扫描+提前终止，很快；但换成SELECT user_name, COUNT(*) FROM t GROUP BY user_name，若没给user_name建索引，就一定触发临时表 + filesort
统计信息不准导致优化器“主动放弃”索引
MySQL 依赖表的统计信息（如索引基数、数据分布）选执行计划。如果表数据大量变更但没更新统计信息，优化器可能误判“走索引比全表还慢”，从而跳过索引。
- 大批量
INSERT/DELETE后，执行ANALYZE TABLE table_name强制刷新统计信息 - 某些 OLAP 场景下，单次查询返回结果占全表比例过高（比如 > 20%），优化器确实会倾向全表扫描——这时加索引也没用，得考虑分区或物化视图
- 用
FORCE INDEX可临时指定索引，但只是绕过问题，不是根治；真正要查的是：为什么优化器觉得它慢？是不是索引设计本身覆盖不足？
索引失效不是玄学，本质是优化器在成本模型下做的理性选择。看清 EXPLAIN 的每列含义，比背场景更重要；而最容易被忽略的，往往是统计信息滞后和复合索引中范围查询对后续列的截断效应。
