索引失效场景全解析：避免数据库崩溃的陷阱
数据库索引是提升查询性能的核心工具，但当索引失效，数据库可能因全表扫描而急剧耗损资源，最终导致崩溃。本文全面解析索引失效的常见场景，帮助开发者和运维人员避开这些陷阱，确保系统稳定运行。
索引失效的常见原因：从查询条件到数据分布
索引失效并非随机发生，而是由特定操作或数据特征触发。最常见的场景包括：对索引列使用函数（如WHERE DATE(create_time) = '2023-01-01'），这迫使数据库逐行计算而非直接利用B+树结构；模糊查询以通配符开头（如%keyword），导致索引无法定位起始点；隐式类型转换（如数字列与字符串比较），破坏索引的精确匹配逻辑。此外，数据分布不均（如某个值占比超过30%时，数据库可能放弃索引选择全表扫描），或查询返回大量行（占总行数20%以上），索引的随机访问成本反超顺序扫描，同样会失效。
这些陷阱的共同特征是：索引无法快速缩小数据范围，迫使数据库执行全表扫描。当数据量达到百万级或并发查询激增时，IO和CPU压力骤升，数据库崩溃风险显著增加。
避免索引失效的关键陷阱：查询优化与索引设计
陷阱一：函数与计算操作
在索引列上使用函数或数学运算是最隐蔽的陷阱之一。例如WHERE price * 1.1 > 100，数据库必须计算每行的price值，索引完全失效。解决方案是将计算迁移到等号右侧，或使用虚拟列存储计算结果并建立索引。对于日期查询，优先使用范围条件（如WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02'）而非函数。
陷阱二：组合索引的列顺序错误
组合索引遵循“最左前缀原则”。若索引为(a, b, c)，查询条件只有b或c时，索引失效。例如查询WHERE b = 10 AND c = 5，数据库无法利用索引。设计组合索引时，应将选择性高的列放在左侧，且查询条件必须包含最左列。若无法避免，可创建独立索引或调整查询顺序。
陷阱三：OR条件与NULL值
OR条件中只要有一个字段未建立索引，整个查询可能失效。例如WHERE name = 'Alice' OR age > 30，若age无索引，数据库只能全表扫描。解决方案是将OR改写为UNION，或为所有涉及列建立索引。此外，索引通常不存储NULL值，因此WHERE column IS NULL会导致索引失效，建议设置默认值或使用虚拟列。
实际案例：从慢查询到数据库崩溃
某电商系统在促销活动期间，数据库突然响应超时。分析慢查询日志发现，一条搜索商品的语句WHERE product_name LIKE '%手机%'导致全表扫描。由于product_name列有前缀索引，但通配符在开头，索引完全失效。当并发查询达到5000次/秒时，数据库CPU飙升到100%，最终崩溃。修复方法是将查询改为WHERE product_name LIKE '手机%'并配合全文索引，同时限制模糊查询的使用场景。
另一个案例中，开发者在订单查询中使用WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31'，但order_date列未建立索引，导致每月初的报表查询拖垮数据库。添加复合索引(order_date, status)后，查询时间从30秒降至0.1秒，彻底避免了崩溃风险。
总结：监控与预防的黄金法则
索引失效的核心诱因包括函数操作、模糊前缀、类型转换、组合索引顺序错误以及OR/NULL条件。预防措施有三点：首先，通过EXPLAIN命令定期检查查询执行计划，重点关注type字段是否出现ALL（全表扫描）；其次，避免在索引列上使用函数和计算，优先使用覆盖索引；最后，对高频查询进行压力测试，模拟真实并发场景下的索引效率。数据库崩溃往往始于一次未被发现的索引失效，系统化的监控和代码审查才是长久之道。