索引列顺序导致的性能问题

今天和大家分享一个很有意思的例子，关于索引列的顺序导致的性能问题。 发现数据库的性能比较差,CPU消耗很高,抓了一个awr,发现瓶颈在sql上,top 1的sql是一个很简单的update语句，没有复杂的条件和表关联。 竟然导致CPU 99% 抓了一个explain plan 的report和自己的理解，先简单说明一下表的情况。 表，TEST_NOTIF_REQ_LOG, 主键基于两个列(partition_key,NOTIFICATION_SEQ_NO)，执行计划,update语句,还有数据分布大体如下,可以看到cpu消耗是很高的，走了全表扫描，数据量大概几百万条。

图1.

最后我随机取了两列的值，测试的数据基于这两条数据。 为了模拟，我把数据,staticstics导出到一个测试库里,可以看到查询单条数据的逻辑读还是很高的,没有走索引。

然后加了条件，partition_key, 立刻走了索引，cpu指标一下子到了1，逻辑读也很低，这是我要努力的方向。

删除原来的索引，然后重新索引，按照指定的顺序来建立索引，立马进行验证，但失望的是性能指标并没有任何改变。

重新建立索引，试着用create unique index的方式来建立索引，终于发现问题。

问题基本找到了，然后建立主键，关联产生索引来看看，发现达到了预期的效果。逻辑读很低,cpu消耗也很低。

有的朋友可能说，是不是由于索引没有关联主键导致的这样的问题。如果建立索引还是按照PARTITION_KEY,NOTIFICATION_SEQ_NO

性能应该没有什么差别

测试结果如下