EXPLAIN中type=ALL明确表示索引失效，即发生全表扫描；主因包括对索引列使用函数、隐式类型转换、违反最左前缀原则、索引列参与计算等。
为什么 EXPLAIN 显示 type=ALL 就代表索引失效
这不是“可能失效”，而是明确发生了全表扫描。InnoDB 本该走索引却没走，说明优化器没选中你建的索引，或索引根本无法被用于当前查询条件。EXPLAIN 中 type=ALL 是最直接的信号，比慢日志更早暴露问题。
常见诱因包括：
-
WHERE条件对索引列用了函数（如WHERE YEAR(create_time) = 2023），导致索引无法下推 - 隐式类型转换：比如字段是
VARCHAR，但传入数字参数（WHERE user_id = 123），MySQL 自动转成字符串比较，但索引 B+ 树按字符串排序，可能跳过范围判断 - 联合索引未遵循最左前缀原则：比如索引是
(a, b, c)，但查询只用了b = ?或c = ? - 索引列参与了计算：
WHERE price * 1.1 > 100，哪怕price有索引也无效
如何用 EXPLAIN 快速定位哪一列导致索引失效
重点看 key 和 possible_keys 两列是否一致，再结合 key_len 判断实际用了索引的前几列。
例如执行 EXPLAIN SELECT * FROM orders WHERE status = 'paid' AND user_id > 1000;，如果 possible_keys 包含 idx_status_user（联合索引 (status, user_id)），但 key 是 NULL，说明整个索引都没用上；如果 key 是 idx_status_user 但 key_len 只有 1（假设 status 是 TINYINT），说明只用了第一列，user_id > 1000 没走索引范围扫描——这是典型的“部分失效”。
实操建议：
- 对每个
WHERE子句单独EXPLAIN，比如先查WHERE status = 'paid'，再加AND user_id > 1000，观察key_len是否增长 - 用
SHOW INDEX FROM orders确认索引定义和字段顺序，尤其注意Seq_in_index - 避免在生产环境直接
EXPLAIN FORMAT=JSON，它输出太长；优先用标准格式快速比对
ORDER BY 和 LIMIT 怎么悄悄让索引失效
即使 WHERE 走了索引，ORDER BY 不匹配索引顺序也会触发 filesort；而 LIMIT 在无有效覆盖索引时，可能让优化器放弃使用索引——因为它预估“扫完整索引再排序取前 N 行”不如全表扫描快。
典型陷阱：
-
WHERE a = 1 ORDER BY b DESC，但索引是(a, c, b)：虽然a匹配，但b不是最右列，且中间隔了c，无法利用索引排序 -
SELECT * FROM logs WHERE level = 'ERROR' ORDER BY id DESC LIMIT 10，如果id不在level的联合索引里，就会先过滤再排序，key_len可能正常，但Extra出现Using filesort -
LIMIT值很大（如LIMIT 10000, 20）时，优化器可能认为索引回表成本高，改走全表扫描
验证方法：检查 EXPLAIN 的 Extra 字段是否含 Using filesort 或 Using temporary，这两个出现任一，基本意味着排序/分组没走索引加速。
哪些看似合理操作实际会绕过索引
开发中常以为“语法没错”，结果索引完全不生效。这些行为在测试数据少时看不出问题，数据量一上去就暴雷。
必须警惕的写法：
- 在索引列上使用
!=或NOT IN：如WHERE status != 'cancelled'，除非是唯一值极少数，否则优化器大概率放弃索引 -
LIKE以通配符开头：WHERE name LIKE '%abc'，B+ 树无法从左侧匹配，只能全扫 - 对索引列使用
IS NULL但该列允许 NULL 且没有单独为 NULL 建索引：InnoDB 对 NULL 的处理会让范围判断失效 - 在
IN列表里塞了太多值（比如几百个 ID），MySQL 可能降级为全表扫描，尤其当统计信息不准时
真正可靠的写法是：把 OR 拆成 UNION，把模糊查改成前缀匹配（LIKE 'abc%'），把大 IN 拆成多次小查询或临时表关联。
索引失效往往不是单点问题，而是条件组合、数据分布、统计信息更新频率共同作用的结果。别只盯着 CREATE INDEX，要习惯每次改查询就跑一遍 EXPLAIN，尤其上线前用真实数据量压测。
