MySQL索引未生效主因是优化器基于成本主动放弃，而非索引未建好；需用EXPLAIN查key（是否候选）、type（是否使用）、Extra（是否回表或排序），结合数据分布与B+树逻辑综合判断。
MySQL建了索引却不走索引，绝大多数情况不是索引没建好，而是优化器算完成本后主动放弃了它——你得先确认它“有没有被考虑”，再判断它“为什么被放弃”。
用 EXPLAIN 看清优化器的真实选择
别猜，直接跑 EXPLAIN。关键字段就三个：key、type、Extra。
-
key是NULL？说明优化器根本没把你的索引放进候选池，可能是条件写法让索引列“失序”了（比如LIKE '%张'或WHERE DATE(create_time) = ...） -
type是ALL或index？说明它连候选都没进，或者进了但被筛掉了 -
Extra出现Using filesort或Using temporary？说明排序/分组逻辑压垮了索引的覆盖能力，哪怕key显示用了索引，性能也可能崩
检查索引是否被“隐式排除”
优化器会基于统计信息预估扫描行数，如果它认为走索引要回表几十万次，而全表扫描反而更便宜，就会跳过索引。这种“合理放弃”在小表或高重复值字段上特别常见。
- 执行
ANALYZE TABLE table_name更新统计信息，再跑一次EXPLAIN，有时rows值会变，决策也会变 - 查一下字段区分度：
SELECT COUNT(DISTINCT status) / COUNT(*) FROM t_order。如果结果 - 注意数据量阈值：空表或只有几百行时，优化器常直接选
ALL，这不是 bug，是设计使然
验证联合索引是否“只用了一半”
联合索引 idx_user_status_time(user_id, status, create_time) 不是“三个字段打包可用”，而是严格按顺序提供有序性支撑。
-
WHERE status = 1→key为NULL，头丢了，整个索引失效 -
WHERE user_id = 100 AND status > 1→key_len只显示前两字段长度，create_time无法用于定位（但可能在引擎层过滤，看Extra是否含Using index condition） -
WHERE user_id = 100 ORDER BY create_time→ 即便key正确，Extra若出现Using filesort，说明排序无法复用索引顺序，create_time必须加到索引末尾才能消除
警惕那些“看着合理实则断链”的写法
很多 SQL 表面符合语法，却在底层切断了索引与 B+ 树的映射关系。
-
WHERE name = 'Alice' OR age = 25→ 如果age没索引，整条语句退化为全表扫描；即使两边都有索引，MySQL 5.7+ 也未必合并使用，key可能只显示其中一个 -
WHERE name LIKE '%li%'→ 前导通配符让 B+ 树无法定位起始节点，只能全扫叶子链表 -
WHERE id + 1 = 100或WHERE CAST(name AS CHAR) = 'Alice'→ 索引列被计算或转换，原始值序列和运算结果序列不一致，索引失效 -
WHERE name = 123（name是VARCHAR）→ 隐式类型转换触发全表扫描，错误日志里甚至不会报错
真正卡住人的，往往不是“索引建没建”，而是“建了但没对上B+树的查找逻辑”，或是“优化器比你更懂这张表的数据分布”。每次怀疑索引失效，先 EXPLAIN，再看 key_len 和 Extra，最后结合字段实际数据分布做判断——绕过这三步，光改SQL或加索引，只是在原地打转。
