组合索引中列的顺序问题

组合索引中列的顺序对执行计划的影响比较大。下面先简单介绍组合索引的适用场景，后面再根据一个具体的SQL说说组合索引中列的顺序对DM7执行计划的影响。

1、使用组合索引查询的场景

兹有 Index (A,B,C) ——组合索引多字段是有序的，并且是个完整的BTree 索引。

下面条件可以用该组合索引查询：

A>5

A=5 AND B>6

A=5 AND B=6 AND C=7

A=5 AND B IN (2,3) AND C>5

 

下面条件将不能用该组合索引查询：

B>5 ——查询条件不包含组合索引首列字段

B=6 AND C=7 ——查询条件不包含组合索引首列字段

下面条件将能用部分组合索引查询：

A>5 AND B=2 ——当范围查询使用第一列，查询条件仅仅能使用第一列

A=5 AND B>6 AND C=2 ——范围查询使用第二列，查询条件仅仅能使用前二列

2、使用组合索引排序的各种场景

兹有组合索引 Index(A,B)。

下面条件可以用该组合索引排序：

ORDER BY A——首列排序

A=5 ORDER BY B——第一列过滤后第二列排序

ORDER BY A DESC, B DESC——注意，此时两列以相同顺序排序

A>5 ORDER BY A——数据检索和排序都在第一列

 

下面条件不能用该组合索引排序：

ORDER BY B ——排序在索引的第二列

A>5 ORDER BY B ——范围查询在第一列，排序在第二列

A IN(1,2) ORDER BY B ——理由同上

ORDER BY A ASC, B DESC ——注意，此时两列以不同顺序排序

 

3、组合索引的执行计划的影响

先看一条查询的SQL：

分析下这条SQL该如何建索引，根据UCAP_DEPT这个表中的记录数，可以判断通过DEPT_BELONGTO能够过滤很多记录，这条SQL最好的计划应该是先将

的结果查询出来，然后再进行后续查询。

a)    先建索引：

收集统计信息：

看看执行计划：

可惜不是最优的计划，但是这个计划在并发的情况下速度不会慢的，代价也很小。在目前的版本里面这个计划算是最优的。

b)  再建索引

根据上面的计划，走NEST LOOPINDEX JOIN2的话，按照下面的索引顺序建索引是否会好点呢？

收集统计信息：

此时的执行计划：

可以看到在第8行，一个走的是NEST LOOP INDEXJOIN2一个走的是HASH2 INNER JOIN我们知道，走hash的话对内存等要求比较高，并发下面占用内存比较多。所以这个a的索引顺序比较合适。因为目前系统刚上线数据量比较小，后期数据量大的话效果会更明显。并且但从计划上面也可以看出，就目前的数据量来看，a的索引顺序比b的代价要小，并且实际执行的时间比b的也快1被以上（K1环境）。

4、Oracle中索引顺序的影响

上面的SQL在Oracle中测试了下，发现Oracle中索引的顺序没有影响，2种索引计划一样：