在给客户巡检时，发现一个用PL/SQL Developer执行的效率低下SQL,通过执行计划可以看到，对Cost影响较大部分为IDX_TS_UH_ORDER_GOODS_1表的索引跳扫，Cost值157，虽然只有157，但是对走索引来说，157的Cost已经很大了，如果正常索引扫，这个值会小很多，而且INDEX SKIP SCAN的结果和HASH JOIN SEMI循环，导致总Cost达到287M(100)，如果能将索引跳扫的Cost从157降下来，INDEX SKIP SCAN的结果和HASH JOIN SEMI循环的总Cost就会成几何下将，这个SQL优化重点也是使索引跳扫改成正常索引扫，猜测产生索引跳扫的原因可能是IDX_TS_UH_ORDER_GOODS_1表上存在复合索引，而该表的ORDER_ID列不是复合索引的第一列，解决方法：在IDX_TS_UH_ORDER_GOODS_1表的ORDER_ID列上单独建立索引。

    这篇文章是以 MySQL 为背景，很多内容同时适用于其他关系型数据库，需要有一些索引知识为基础 优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。降低 CPU 计算除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的