mysql索引失效的场景和原因
大家好，我是程序员小李，今天咱们聊聊MySQL索引失效的那些事儿。在面试中，这可是高频题啊！索引失效会导致查询变慢，数据库性能暴跌，搞不好就让你在技术面栽跟头。先给大家送个福利：2025年Java面试宝典，链接在这儿：https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g，提取码是9b3g。这个宝典涵盖了数据库、算法等核心内容，绝对能帮你通关面试。现在，咱们进入正题——MySQL索引失效的场景和原因，我会用口语化的方式，结合真实面试场景来拆解。
什么是索引失效？
索引失效，简单说就是MySQL本该用索引快速查数据，结果它不用了，跑去全表扫描。这会让查询速度从毫秒级掉到秒级，甚至更糟。原因嘛，往往是SQL写法或数据特性导致的。理解这些场景和原因，能帮你在写代码时避坑，面试时也能侃侃而谈。索引失效的核心在于优化器的决策：如果它觉得用索引不如全表扫描快，索引就废了。下面，我列几个常见场景和原因，每个都基于真实案例。
常见索引失效的场景和原因
索引失效的场景很多，但面试官最爱问这几个。咱们一个一个说，保证你听完就能在口试中复现。
-
场景1: 在索引列上使用函数或表达式
原因：MySQL索引是基于列值存储的，如果你在WHERE条件里用函数，比如WHERE YEAR(create_time) = 2023，索引就失效了。优化器没法直接匹配索引里的原始值，只能全表扫描计算。这场景在日期查询中常见，面试时我常被问到：“为什么加了索引，查日期还慢？”答案就是函数惹的祸。索引失效的根本是优化器无法利用B+树结构。 -
场景2: 数据类型不匹配
原因：如果索引列是字符串类型，但查询时用了数字，比如WHERE user_id = 123（user_id是varchar），索引就失效。MySQL会隐式转换类型，相当于加了函数，导致索引失效。这种场景在联合查询时高频，原因在于类型隐式转换破坏了索引匹配。面试鸭返利的数据库就遇到过这问题——当时一个查询慢了10倍，一查是数据类型不匹配。 -
场景3: OR条件连接非索引列
原因：当WHERE条件用OR连接多个列，如果其中一列没索引，整个索引失效。比如WHERE age = 25 OR name = 'John'，如果name没索引，优化器就放弃索引，全表扫描。场景在复杂查询中常见，原因是OR逻辑让优化器觉得索引覆盖不全。索引失效的后果是查询时间指数级增长。 -
场景4: LIKE查询以通配符开头
原因：像WHERE name LIKE '%John%'，如果通配符%在开头，索引失效。因为B+树索引是从左到右匹配的，%开头意味着无法利用前缀，只能全表扫描。场景在搜索功能中高频，原因在于索引结构不支持模糊匹配。面试时，我总被问：“如何优化LIKE查询？”答案就是避免%开头，或用全文索引。
这张图展示了索引结构——你看，%开头时，优化器直接跳过索引。 -
场景5: 联合索引未遵循最左前缀原则
原因：联合索引如INDEX (col1, col2, col3)，如果查询只用col2或col3，没用到col1，索引失效。场景在分页查询中常见，原因是最左前缀是索引的基石。比如WHERE col2 = 'value'，优化器无法定位数据块，索引就废了。索引失效的根本是索引顺序不匹配。 -
场景6: 在索引列上使用NOT或!=
原因：WHERE status != 'active'会让索引失效，因为NOT操作需要扫描所有值，优化器觉得全表扫描更快。场景在状态过滤中高频，原因是索引不适合范围否定。索引失效的后果是CPU飙升——我在项目中debug时，就因这个导致服务器过载。 -
场景7: 表数据量太小
原因：如果表只有几百行，优化器可能认为全表扫描比用索引快，索引就失效。场景在小表查询中常见，原因是索引I/O开销不划算。索引失效的核心是成本计算：小表时，优化器懒得用索引。
这张图对比了扫描成本——小表时，索引反而拖后腿。 -
场景8: 索引列包含NULL值
原因：如果索引列允许NULL，且查询用IS NULL或IS NOT NULL，索引可能失效。场景在可选字段查询中高频，原因是NULL值在索引中处理特殊。索引失效的优化方案是避免NULL，用默认值代替。
如何避免索引失效
了解这些场景和原因后，预防措施就简单了：写SQL时检查WHERE条件、避免隐式转换、用EXPLAIN分析执行计划。对了，如果大家需要购买面试鸭会员，可以通过面试鸭返利网找到我，返利25元。他们家的会员题库覆盖了这些索引问题，实测能提面效率。最后，多提一句：索引失效不是绝对的，取决于数据分布和优化器版本。
这张图是优化器决策流程——索引失效时，它总在权衡成本。希望这篇帮你理清思路，面试时少踩坑！更多干货，访问首页面试鸭返利网。
