Oracle 当它也是多列索引中的第一个时，是否推荐使用单列索引？

嗨
我有一个有大约百万行和大约30列的表。
表名称:-示例表
列:- A，B，C，D，E，……..

该表上有多个索引，其中两个索引如下所示

Create index idx_1 on example_table(A) ;
Create index idx_2 on example_table(A,B,C,D);
复制

在这里，您可以看到，列A用于Sigle列索引和多列索引。
是否建议在列A上使用单列索引，因为它在多列索引中作为第一列存在，或者只是该表上的开销？

也许吧。

虽然两者都是在列A上搜索的候选者，但您可能会发现在多列索引不是的某些情况下使用了单列索引。

例如，让我们创建一个表，并在其上创建一个三列索引:

create table t ( 
  c1 constraint pk primary key, c2 not null, c3 not null, c4 not null
) as 
  select level c1, ceil ( level / 100 ) c2, 
         date'2021-01-01' + mod ( level, 37 ) c3,
         lpad ( 'stuff', 100, 'f' ) c4
  from   dual
  connect by level <= 10000;
  
create index i231 on t ( c2, c3, c1 );
复制

对索引的前导列的查询返回1% 行，但优化器选择全表扫描:

set serveroutput off

select * from t 
where  c2 = 1;

select * 
from   table(dbms_xplan.display_cursor(null, null, 'BASIC LAST'));

----------------------------------    
| Id  | Operation         | Name |    
----------------------------------    
|   0 | SELECT STATEMENT  |      |    
|   1 |  TABLE ACCESS FULL| T    |    
----------------------------------
复制

但是仅在此列和优化器上创建索引does使用它:

create index i2 on t ( c2 );

select * from t
where  c2 = 1;

select * 
from   table(dbms_xplan.display_cursor(null, null, 'BASIC LAST'));

----------------------------------------------------    
| Id  | Operation                           | Name |    
----------------------------------------------------    
|   0 | SELECT STATEMENT                    |      |    
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T    |    
|   2 |   INDEX RANGE SCAN                  | I2   |    
---------------------------------------------------- 
复制

因此... 这是为什么？

有几个原因。

首先，单列较小-其中的数据较少。所以读起来更快。

其次，多列指数的聚类因子要高得多-高出20倍以上:

select index_name, leaf_blocks, clustering_factor
from   user_indexes
where  table_name = 'T';

INDEX_NAME   LEAF_BLOCKS   CLUSTERING_FACTOR   
PK                    20                 170 
I231                  37                7250 
I2                    20                 170 
复制

聚类因子是决定索引效果的关键因素，从而决定了优化器选择它的可能性 (更低 = 更好)。列越少，聚类因子可能越低。

创建尽可能少的索引是一个好主意。但是，如该示例所示，可能存在创建 “冗余” 索引会导致更快的查询的情况。