[面试题] Oracle LIKE查询优化：WHERE子句中使用‘%abc’时如何选择索引？

在Oracle数据库的性能调优中，SQL查询的索引使用是一个核心议题。一个常见且值得深入探讨的场景是：当我们对VARCHAR2类型的列执行模糊查询，并且在WHERE子句中使用了LIKE ‘%abc’这样的模式时，数据库的索引行为会是怎样的呢？理解这一点，对于进行有效的数据库性能调优至关重要。

请判断以下针对该场景的说法，哪一个是正确的？

A、这个查询无法使用该列上的B树索引。
B、这个查询总是能很好地利用该列上的B树索引。
C、在这个列上创建反向键索引可以提升此查询性能。
D、在这个列上创建位图索引是最佳选择。

问题解析与答案

这道题考察的是Oracle数据库中，当使用前导通配符%进行模糊查询时，B树索引的可用性问题。

• 关键点：对于LIKE ‘%abc’这样的查询模式，由于搜索条件以通配符%开头，Oracle无法有效利用列上普通的B树索引进行快速的范围扫描（Range Scan）。数据库通常需要执行全索引扫描或全表扫描来匹配所有以“abc”结尾的值，这使得索引的效率大打折扣，甚至可能不如全表扫描。因此，说法A“这个查询无法使用该列上的B树索引”是准确的。注意，这里“无法使用”更严谨的理解是“无法有效利用其快速定位的特性”，但索引本身仍可能被用于全索引扫描。

• 选项分析：

  • B：错误。如前所述，前导%会导致索引失效，无法“很好地利用”。
  • C：错误。反向键索引（Reverse Key Index）是将索引键值的字节顺序反转，主要用于缓解索引热点块问题（如在序列字段上），它并不能解决前导%导致的索引失效问题。对于LIKE ‘%abc’，反转后的键值同样无法被有效匹配。
  • D：错误。位图索引（Bitmap Index）适用于低基数（即列值唯一性低）的列，在数据仓库等OLAP场景中用于多条件组合查询。在OLTP系统中，或者对VARCHAR2列进行频繁更新时，使用位图索引通常不合适，并且它同样无法优化LIKE ‘%abc’这种模式匹配查询。

因此，本题的正确答案是 A。

希望这个简单的技术选择题能帮助大家巩固对Oracle索引工作原理的理解。如果你有更多关于SQL优化或数据库实践的疑问，欢迎在云栈社区与更多开发者一同交流探讨。