mysql索引失效的情况

大家好，我是面试鸭的资深程序员，今天和大家聊聊MySQL索引失效的情况。这可是面试中的高频题啊！不管是初级还是高级岗位，几乎每次面试都会被问到。索引失效会导致查询性能暴跌，数据库卡顿，甚至引发线上事故，所以搞懂这些坑点至关重要。哦对了，推荐大家下载2025年Java面试宝典，干货满满：链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g（网盘链接，重要资源，先存起来！）。好，咱们进入正题——MySQL索引失效的情况，我会从真实面试场景出发，口述常见情况，帮你轻松应对。

MySQL索引失效的常见原因

在MySQL中，索引失效可不是小事儿。一旦发生，查询速度从毫秒级降到秒级，影响用户体验。关键是，面试官最爱考这些细节。我来分享几个高频失效场景，都是实战中踩过的坑。

MySQL索引失效场景一：查询中使用函数

在面试中，我常被问：“如果WHERE子句用了函数，索引会怎么样？” 答案是大概率失效。比如，你有个日期字段加了索引，但你写成 WHERE YEAR(date_column) = 2023。MySQL优化器这时就蒙圈了，因为它无法直接利用索引的排序结构，只能全表扫描。记住，任何函数包裹索引列，如 UPPER(name) 或 DATE_FORMAT(date, '%Y')，都容易引发MySQL索引失效。面试时，我会强调：尽量把函数移到应用层处理，避免在SQL里操作。

MySQL索引失效场景二：OR操作符连接不同列

面试官问：“OR条件会影响索引吗？” 必须会！比如 WHERE column1 = 'value' OR column2 = 'value'。如果这些列各自有索引，但OR连接后，MySQL可能放弃使用索引，转向全表扫描。原因是优化器觉得合并索引成本太高。这就是典型的MySQL索引失效情况。我建议用UNION替代OR，或者确保所有列在同一个组合索引中。

MySQL索引失效场景三：LIKE以通配符开头

这个问题在面试中很常见：“LIKE '%pattern' 能用索引吗？” 答案是否定的。索引是基于前缀匹配的，像 LIKE '%abc' 或 LIKE '_abc'，优化器无法利用B+树的顺序性，导致索引失效。但如果写成 LIKE 'abc%'，索引就正常生效。面试时，我会解释：通配符放开头，MySQL只能遍历所有记录，引发性能问题。

MySQL索引失效场景四：数据类型不匹配

面试官常问：“为什么字符串索引用数字比较会出问题？” 这源于隐式类型转换。比如索引列是VARCHAR，但你写 WHERE name = 123。MySQL会悄悄转成 WHERE name = '123'，但优化器不知道，以为类型不匹配，就放弃索引。这种MySQL索引失效很隐蔽，平时要养成显式转换的习惯，如用 CAST 或确保类型一致。

MySQL索引失效场景五：索引列参与计算

面试题：“WHERE column + 1 = 5 能用索引吗？” 通常不行。任何计算操作，如 WHERE salary * 1.1 > 5000 或 WHERE SUBSTR(name, 1, 3) = 'abc'，都让索引失效。因为索引存储的是原始值，计算后值变了，优化器无法匹配。我会在面试中建议：把计算移到右边，比如 WHERE salary > 5000 / 1.1。

MySQL索引失效场景六：使用NOT操作符

面试官问：“NOT IN 或 NOT NULL 会影响索引吗？” 是的，尤其是NOT IN或NOT EXISTS。比如 WHERE id NOT IN (1,2,3)，优化器可能认为扫描全表更快，导致索引失效。类似地，IS NOT NULL在特定场景下也失效。应对策略是尽量用正逻辑，或用LEFT JOIN优化。

MySQL索引失效场景七：优化器选择全表扫描

这个在面试中常被忽视：“为什么有时优化器不用索引？” MySQL内部有个成本模型，如果表很小（如几百行），或索引选择性低（如布尔字段），优化器会判定全表扫描更快。这叫“聪明的失效”，不算错误，但面试时要解释清楚。比如一个表只有10行，用索引反而慢。

聊到这里，大家对这些MySQL索引失效情况有概念了吧？如果面试官追问，我再补充点：组合索引的顺序也很关键——如果WHERE没命中第一列，索引可能失效。另外，统计信息过期也会误判。好，面试鸭的资源很丰富，包括会员服务。如果大家需要购买面试鸭会员，可以通过面试鸭返利网找到我，返利25元！访问面试鸭返利网获取专属优惠。

这张图展示了会员福利，快去看看吧。