索引失效的场景

🔍 索引失效的场景：程序员必知的数据库性能陷阱

📥 2025年Java面试宝典网盘地址：
链接 👉 提取码: 9b3g

---

🤔 为什么你的SQL跑得慢？索引失效的6大坑

作为程序员，面试时被问“哪些场景会导致索引失效？”就像家常便饭。但工作中真遇到慢查询，很多人还是抓瞎。今天我们就以MySQL为例，聊聊那些索引失效的典型场景，帮你少踩坑！

🧩 场景1：最左前缀匹配失效

假设你建了联合索引 (name, age, city)，但查询时跳过了name：

SELECT * FROM users WHERE age = 25 AND city = 'Beijing';  

📌 为什么失效？
联合索引遵循最左匹配原则。没有name开路，索引就像没钥匙的门——打不开。

🔢 场景2：对索引列做计算或函数处理

SELECT * FROM orders WHERE YEAR(create_time) = 2023;  

📌 致命错误：
对索引列create_time用YEAR()函数后，数据库无法直接定位数据，只能全表扫描！
✅ 正确姿势：

SELECT * FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';  

⚖️ 场景3：隐式类型转换

字段phone是varchar，但你这么查：

SELECT * FROM users WHERE phone = 13800138000;  -- 数字 vs 字符串  

📌 后果：
数据库偷偷做了类型转换，相当于在查询条件外包了一层CAST()——索引当场罢工！

❌ 场景4：用!=或NOT IN

SELECT * FROM products WHERE status != 'offline';  

📌 真相：
!=和NOT IN会让优化器放弃索引。因为非等值查询的结果集可能超大，走索引反而更慢。

🔀 场景5：模糊查询乱用%

SELECT * FROM articles WHERE title LIKE '%数据库%'; -- 开头通配符  

📌 杀伤力：
开头的%让索引树无法定位起始点，只能硬着头皮扫描全部数据！

📉 场景6：OR连接非索引字段

SELECT * FROM employees  
WHERE dept_id = 10 OR salary > 10000;  -- salary无索引  

📌 陷阱：
只要OR一侧的列没索引，整个查询直接退化成全表扫描！

---

🛠️ 如何避免索引失效？

1. 写SQL前看索引：执行EXPLAIN分析查询计划
2. 慎用函数：尽量对条件值做计算，别动索引列
3. 类型一致：确保WHERE条件的类型与字段定义匹配
4. 前缀查询：模糊匹配尽量用keyword%

💡 福利时间：
如果你需要开通【面试鸭】会员刷真题，通过👉 面试鸭返利网 👈找我可返现25元！海量大厂题库+会员优惠双重加持 🚀

---

索引失效不是玄学，而是优化器在成本和效率间的权衡。下次写SQL时多看一眼执行计划，或许就能避免一次深夜加班救火！ 🔥

← 返回首页