Is the order of attributes in a unique index still important in Oracle 12c? The internet mostly says, the order in a unique index does matter for the reasons of index search tree structure, but a colleague stated, Oracle changed that recently.

I can't find any information on such a change in the docs.

Is the order still influencing look-up speed for a unique index?
Why not quickly test it yourself?

SQL&gt; alter session set statistics_level=all;

Session altered.

SQL&gt; create table t1 (c1, c2) as select 1, rownum from dual connect by level &lt;= 1000000;

Table created.

SQL&gt; alter table t1 add unique(c1, c2);

Table altered.

SQL&gt; exec dbms_stats.gather_table_stats(user, 'T1');

PL/SQL procedure successfully completed.

SQL&gt; select /*+ index(t1) */ * from t1 where c2 = 100;

        C1         C2
---------- ----------
         1        100

SQL&gt; select * from table(dbms_xplan.display_cursor(format=&gt;'allstats last'));

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  1mu7dt5d4j8tb, child number 0
-------------------------------------
select /*+ index(t1) */ * from t1 where c2 = 100

Plan hash value: 1797320280

---------------------------------------------------------------------------------------------------
| Id  | Operation        | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |             |      1 |        |      1 |00:00:00.01 |       8 |      1 |
|*  1 |  INDEX SKIP SCAN | SYS_C008413 |      1 |      1 |      1 |00:00:00.01 |       8 |      1 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("C2"=100)
       filter("C2"=100)


Not that bad, but using the proper order:

SQL&gt; alter table t1 drop unique(c1, c2);

Table altered.

SQL&gt; alter table t1 add unique(c2, c1);

Table altered.

SQL&gt; select /*+ index(t1) */ * from t1 where c2 = 100;

        C1         C2
---------- ----------
         1        100

SQL&gt; select * from table(dbms_xplan.display_cursor(format=&gt;'allstats last'));

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  1mu7dt5d4j8tb, child number 0
-------------------------------------
select /*+ index(t1) */ * from t1 where c2 = 100

Plan hash value: 2004096996

---------------------------------------------------------------------------------------------------
| Id  | Operation        | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |             |      1 |        |      1 |00:00:00.01 |       4 |      2 |
|*  1 |  INDEX RANGE SCAN| SYS_C008414 |      1 |      1 |      1 |00:00:00.01 |       4 |      2 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("C2"=100)


18 rows selected.


Still better.