Composite indexes: Most selective column first?
From AskTom


  (in 9i, there is a new "index skip scan" -- search for that there to read about that. It makes the index (a,b) OR (b,a) useful in both of the above cases sometimes!) 
  
  So, the order of columns in your index depends on HOW YOUR QUERIES are written. You want to be able to use the index for as many queries as you can (so as to cut down on the over all number of indexes you have) -- that will drive the order of the columns. Nothing else (selectivity of a or b does not count at all).


One of the arguments for arranging columns in the composite index in order from the least discriminating(less distinct values) to the most discriminating(more distinct values) is for index key compression.

SQL&gt; create table t as select * from all_objects;

Table created.

SQL&gt; create index t_idx_1 on t(owner,object_type,object_name);

Index created.

SQL&gt; create index t_idx_2 on t(object_name,object_type,owner);

Index created.

SQL&gt; select count(distinct owner), count(distinct object_type), count(distinct object_name ), count(*)  from t;

COUNT(DISTINCTOWNER) COUNT(DISTINCTOBJECT_TYPE) COUNT(DISTINCTOBJECT_NAME)      COUNT(*)
-------------------- -------------------------- --------------------------      ----------
                 30                         45                       52205      89807

SQL&gt; analyze index t_idx_1 validate structure; 

Index analyzed.

SQL&gt; select btree_space, pct_used, opt_cmpr_count, opt_cmpr_pctsave from index_stats;

BTREE_SPACE   PCT_USED OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
----------- ---------- -------------- ----------------
    5085584     90          2           28

SQL&gt; analyze index t_idx_2 validate structure; 

Index analyzed.

SQL&gt; select btree_space, pct_used, opt_cmpr_count, opt_cmpr_pctsave  from index_stats; 

BTREE_SPACE   PCT_USED OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
----------- ---------- -------------- ----------------
    5085584     90          1           14


According to the index statistics, the first index is more compressible. 

Another is how the index is used in your queries.
If your queries mostly use col1,  

For example, if you have queries like-
select * from t where col1 = :a and col2 = :b; 
select * from t where col1 = :a;

-then index(col1,col2) would perform better. 

If your queries mostly use col2,
select * from t where col1 = :a and col2 = :b; 
select * from t where col2 = :b; 

-then index(col2,col1) would perform better.
If all of your queries always specify both columns then it doesn't matter which column come first in the composite index.

In conclusion,
the key considerations in column ordering of composite index are index key compression and how you are going to use this index in your queries. 

References:
Column order in Index
It’s Less Efficient To Have Low Cardinality Leading Columns In An Index (Right) ?
Index Skip Scan – Does Index Column Order Matter Any More ? (Warning Sign)