mysql数据库索引失效的常见原因_分析索引设计与使用误区

MySQL索引失效主因有三：WHERE中对字段用函数或表达式（如YEAR(create_time)）、复合索引中范围查询后列无法命中、统计信息过期或数据倾斜致优化器误判；需改写为范围条件、定期ANALYZE TABLE并警惕隐式转换。WHERE 条件用了函数或表达式导致 index 失效MySQL 无法对计算后的结果使用索引，哪怕字段本身有索引。比如 WHERE YEAR(create_time) = 2023，create_time 上有索引也没用——因为优化器要先算出每行的 YEAR()，再比对，没法走 B+ 树的有序查找。常见场景：日期按年/月查询、字符串 UPPER()/LOWER() 比较、CONCAT() 拼接后匹配。改写为范围查询：WHERE create_time >= '2023-01-01' AND create_time 避免在索引列上做任何运算，包括隐式类型转换（如 WHERE user_id = '123' 而 user_id 是 INT）真需要函数检索，考虑生成列 + 函数索引（MySQL 5.7+ 支持 STORED 列，8.0+ 支持函数索引）LIKE 查询以通配符开头触发全表扫描LIKE '%abc' 或 LIKE '%abc%' 会让索引失效，因为 B+ 树是按前缀有序组织的，没法从中间或结尾反向定位。只有 LIKE 'abc%' 这种左前缀模式才能用上索引（前提是该字段是联合索引最左列或独立索引）。模糊搜索需求强烈时，别硬扛，考虑 FULLTEXT 索引或外部搜索引擎（如 Elasticsearch）如果只是查“是否包含某子串”，且数据量不大，INSTR() 或正则可能更直白，但同样不走索引注意 LIKE 的 ESCAPE 字符设置错误也会导致计划异常，可用 EXPLAIN 验证 key 字段是否为空联合索引没遵循最左前缀原则联合索引 (a, b, c) 实际上只建立了三个有效索引路径：a、(a,b)、(a,b,c)。跳过 a 直接查 b 或 (b,c)，索引就完全失效。 文心快码 文心快码（Comate）是百度推出的一款AI辅助编程工具