索引为什么有时不生效：数据库索引的常见误解

一、索引的本质是有序的数据结构

常见数据库的索引大多基于 B+ 树。它的价值在于把全表扫描变成树查找，把复杂度从线性降到对数级。但这个价值成立的前提是，查询条件能够利用索引的有序性进行快速定位。

一旦查询写法破坏了有序性的使用条件，索引就可能失效，查询退化为全表扫描。

二、最常见的几类失效场景

对索引列使用函数或表达式。例如对创建时间列做日期格式化后再比较，数据库无法直接利用索引中的原始值定位，只能逐行计算后再判断。类似地，索引列参与运算、隐式类型转换，都会导致索引失效。字符串列传入数字、字符集不一致的关联，都属于这一类。

模糊匹配以通配符开头。索引按照列值从左到右排序，最左通配的查询无法确定从哪个位置开始查找，只能全表扫描。

违反最左前缀原则。联合索引按照定义的列顺序组织，查询条件跳过左侧列时，后续列通常无法有效利用索引。联合索引的列顺序应该根据查询频率和区分度设计，而不是随意排列。

范围条件之后的列无法继续走索引。在联合索引中，一旦某一列使用了范围查询，其右侧的列一般只能用于过滤，不能用于索引定位。

三、优化器有时主动放弃索引

即使查询写法没有问题，优化器也可能估算后认为全表扫描更便宜。典型场景是查询条件命中的数据占比过高。当优化器判断需要回表的比例太大，随机 IO 的成本超过顺序扫描时，会主动选择全表扫描。

这类情况说明索引的区分度不足，或者查询本身就不适合用索引解决。盲目强制使用索引，反而可能让查询更慢。

四、排查索引问题的基本方法

第一步是使用执行计划确认索引是否被使用，关注访问类型、使用的索引、扫描行数。第二步是对比预估扫描行数与实际执行耗时，判断问题是出在索引选择还是数据访问本身。第三步是检查表统计信息是否过期，过期的统计信息会误导优化器做出错误决策。

此外，索引并非越多越好。每个索引都会增加写入时的维护成本和存储开销。索引设计应该基于真实的查询模式，定期清理未被使用的索引，与添加新索引同样重要。

五、总结

索引失效的根源可以归结为两类：查询写法破坏了索引的有序性，或者优化器判断索引不划算。理解 B+ 树的组织方式和最左前缀原则，配合执行计划进行验证，是解决大多数索引问题的通用路径。索引是写给查询的，不是写给表的，脱离查询场景谈索引设计没有意义。