Oracle查询全部列时未使用Bitmap索引的问题排查

为什么SELECT *时不触发Bitmap索引扫描？ #

Oracle优化器选择执行计划的核心依据是成本计算，这里的关键原因有两点：

1. 回表开销过高：Bitmap索引仅存储键值和对应行的ROWID，当你查询SELECT *时，数据库需要先通过Bitmap索引找到符合条件的ROWID，再回到表中读取所有列的数据（即「回表」操作）。如果这5%的结果行在表中分布零散，回表带来的随机I/O成本会远高于全表扫描的顺序I/O成本，优化器会倾向于选择全表扫描。
   而当你只查询column_x和带索引的column_y时，优化器可以直接通过两个索引做索引连接，完全不需要回表，成本更低，因此触发了索引关联扫描。
2. Bitmap索引的适用场景限制：Bitmap索引更适合多列组合查询、统计聚合类查询，或者能通过索引覆盖（无需回表）的查询。单一低基数列的Bitmap索引，在需要回表的场景下，优化器通常会判定全表扫描的成本更低。

无需全列建索引的解决方案 #

不用为每列创建索引，可尝试以下几种方案：

• 创建覆盖Bitmap索引：在Oracle 12c及以上版本，你可以用INCLUDE子句把查询需要的所有列加入索引，比如：

  CREATE BITMAP INDEX idx_table1_x_include ON table_1(column_x) 
  INCLUDE (col_a, col_b, col_c, ...); -- 替换为你需要查询的所有列
  

  这样查询SELECT *时，数据库可以直接从索引中获取所有数据，无需回表，优化器就会选择索引扫描。
• 更新统计信息：确保表和索引的统计信息是最新的，执行以下命令刷新：

  DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => '你的用户名', TABNAME => 'TABLE_1', CASCADE => TRUE);
  

  优化器依赖准确的统计信息计算成本，过时的统计信息可能导致执行计划选择偏差。
• 使用查询提示强制索引：如果确认索引扫描确实更高效，可以在查询中添加提示强制走索引：

  SELECT /*+ INDEX(table_1 idx_table1_x) */ * FROM table_1 WHERE column_x = 'xyz';
  

  注意：仅当你确定优化器的成本估算错误时再使用提示，避免滥用导致性能问题。

你的操作是否存在问题？ #

你为低基数列创建Bitmap索引的操作本身没有错误——低基数列正是Bitmap索引的适用场景之一。你遇到的只是优化器基于成本模型选择执行计划的正常现象，并非操作失误。需要注意的是，Bitmap索引不适合高并发的DML操作（因为会锁定整个键值对应的所有行），如果你的表有频繁的插入、更新或删除操作，可能需要考虑其他索引类型。

内容的提问来源于stack exchange，提问作者UrDailyCS