Ordering of columns in COMPOSITE INDEXES Composite or Concatenated indexes are multi-column indexes.

The optimizer will take into account a composite index when the WHERE clause in a query refers to all the columns in the index or even the leading column. This was traditional behaviour. The introduction of INDEX SKIP SCAN changes this default behaviour. In earlier releases of the Oracle Database, a SQL statement used a composite index only if the statement's constructs used a leading portion of the index. The leading portion of an index is one or more columns in the index that are specified first in the list of columns. For example, say you have the following composite index:

create index comp_idx on table table(a,b,c);

In this index, a, ab, and abc are all considered leading portions of an index. The column or column combinations b, c, and bc aren't considering leading portions. However, the introduction of the index skip scan feature (in the Oracle 9i release) has changed this behavior. An index skip scan eliminates or skips through a composite index by using logical subindexes. Logical subindexes mean just that: you don't create those indexes. The skip scanning feature assumes that the composite index is indeed composed of multiple subindexes. STEP 1 : CREATE A TABLE EMPLOYEE_ENTITY of 100000 rows as shown in the following script

EMPLOYEE_ENTITY.sql

No. of BLOCKS in the table = 251 STEP 2: INDEX the columns LASTNAME, JOB_ID, GENDER in 6 different orders LASTNAME has highest cardinality (all distinct values) JOB_ID has medium cardinality (few distinct values) GENDER has lowest cardinality (very few distinct values, only M and F)

IND.sql

STEP 3 : Get the clustering factor for each index :

INDEX NAME EE_GJL_CI EE_GLJ_CI EE_JGL_CI EE_JLG_CI EE_LGJ_CI EE_LJG_CI 9004 17805 9004 9886 25097 25097

CLUSTERING FACTOR

Based on the table above, EE_GJL_CI and EE_JGL_CI are the best ordered index (despite the clustering factor being much higher than the number of blocks) and even though GENDER column has low cardinality. STEP 4 : Performance statistics:
DEFAULT OPTION USED BY OTIMIZER

INDEXES \ QUERIES Q1 Lastname, job_id and gender

EE_LJG_CI

EE_LGJ_CI

EE_JGL_CI

EE_JLG_CI

EE_GLJ_CI

EE_GJL_CI

Q1.sql

EE_GJL_CI

cost = 2 INDEX RANGE SCAN

cost = 2 INDEX RANGE SCAN

cost = 2 INDEX RANGE SCAN

cost = 2 INDEX RANGE SCAN

cost = 2 INDEX RANGE SCAN

cost = 2 INDEX RANGE SCAN

Q2 Lastname cost = 3 INDEX RANGE SCAN cost = 3 INDEX RANGE SCAN cost = 12 INDEX SKIP SCAN cost = 12 INDEX SKIP SCAN cost = 4 INDEX SKIP SCAN cost = 12 INDEX SKIP SCAN

Q2.sql

EE_LGJ_CI FULL TABLE SCAN COST = 144

Q3 JOB_ID

Q3.sql

cost = 4737 INDEX FULL SCAN

cost = 4737 INDEX FULL SCAN

cost = 2896 INDEX RANGE SCAN

cost = 2984 INDEX RANGE SCAN

cost = 4008 INDEX FULL SCAN

cost = 3128 INDEX FULL SCAN

Q4 GENDER

Q4.sql

FULL TABLE SCAN COST = 144

cost = 22650 INDEX FULL SCAN

cost = 22650 INDEX FULL SCAN

cost = 14600 INDEX FULL SCAN

cost = 15041 INDEX FULL SCAN

cost 18874 INDEX RANGE SCAN

cost 14471 INDEX RANGE SCAN

Q5 LASTNAME, JOB_ID cost = 3 INDEX RANGE SCAN cost = 3 INDEX RANGE SCAN cost = 4 INDEX SKIP SCAN cost = 3 INDEX RANGE SCAN cost = 4 INDEX SKIP SCAN cost = 4 INDEX SKIP SCAN

Q5.sql

EE_JLG_CI

Q6 LASTNAME, GENDER cost = 3 INDEX RANGE SCAN cost = 3 INDEX RANGE SCAN cost = 12 INDEX SKIP SCAN cost = 12 INDEX SKIP SCAN cost = 3 INDEX RANGE SCAN cost = 13 INDEX SKIP SCAN

Q6.sql

EE_GLJ_CI FULL TABLE SCAN COST = 144

Q7 JOB_ID, GENDER

Q7.sql

cost = 2498 INDEX FULL SCAN

cost = 2498 INDEX FULL SCAN

cost = 1449 INDEX RANGE SCAN

cost = 1506 INDEX RANGE SCAN

cost = 2005 INDEX RANGE SCAN

cost = 1449 INDEX RANGE SCAN

IF Full Table Scan is used for all these queries : the cost for all queries is 144 SELECT /*+ full(EMPLOYEE_ENTITY) * from EMPLOYEE_ENTITY WHERE
FTS.sql

CONCLUSION:
When creating a composite index, a big question is how to order the columns in the multi-column index. Oracle recommends that you place the most commonly accessed column first in the index. Traditionally, it was thought that you should avoid using a low cardinality column (a column with few distinct values) as the leading column in a composite index. However, regardless of the index order, the database can navigate straight to the leaf block containing the indexed column values because the index leaf branch entries contain column entries based on all indexed columns. In fact, a leading column with lower cardinality may have more advantages, as the optimizer is likely to at least consider using an index skip scan in these cases. It has also been suggested to use the clustering factor as a criterion when deciding which column should be the leading index column in a composite index. The clustering factor indicates how well ordered the tables rows are in comparison to the way the index entries are ordered in an index. FROM the table above, we can infer that concatenated/ composite indexes are good if we frequently query on columns : (LASTNAME,JOB_ID,GENDER) or (LASTNAME, JOB_ID) or (LASTNAME,GENDER) or (LASTNAME). From the above table, the index EE_LGJ_CI, though having a high clustering factor, is more beneficial* compared to other indexes.

* Based on the columns we specify in the predicate