解决Oracle SQL语句性能问题——合理使用索引

​​​​​​1. 合理使用索引

索引对关系库SQL调优来说，其重要性怎么强调也不会过分。为何这么说呢？因为对SQL调优来讲，最终目的就是通过减少SQL语句对系统资源的消耗来达到优化的目的，而索引又是缩减SQL语句资源消耗的最主要手段。当然，你也可以说，还可以通过为SQL语句分配更多资源来达到优化的目的，但这不是SQL调优手段的主流，拼资源也更不是传统关系库的优势。

可以这么说，如果说一个人真正掌握了索引技术，那么，他就掌握了一大半SQL调优，可现实中，我们没理由不怀疑一个真正掌握了索引技术的人不是位SQL调优领域的高手。记得甲骨文资深技术顾问罗敏在其所著《品悟性能优化》一书中，开篇部分写道：“我其实只懂点IT（挨踢）知识，IT里面其实只懂点甲骨文，甲骨文里面其实只懂点数据库，数据库里面其实只懂点SQL，SQL里面其实只懂点索引”——“你才是真正的专家啊！”，这段内容虽是作者自谦和调侃的话，但也间接说明了索引在数据库优化中的重要地位。

以上我们强调了索引在SQL调优中的重要性，那么，读者现在可能会问，索引简单吗？好学吗？在本人看来，索引既简单也复杂，既好学也难学。读者看到本人的这个回答，可能觉得更糊涂了，甚至觉得本人在故弄玄虚。这里本人澄清下，该回答绝非调侃之词。其实，任何一门技术的学习和掌握都有这么一个过程，最开始觉得这门技术很简单，看几天就觉得学得差不多了；然后，在实际应用该技术时，不知道怎么用，感到无所适从，忽然觉得对这门技术知之甚少，顿感有点头大；最后，通过长期不断的学习和实践，对这门技术用的多了，做到了熟能生巧，同时，也不再拘泥于该技术相关的一些概念和定义等，而是理解和掌握了该技术更深层次的含义和关键要点，于是，会觉得该技术又没那么复杂了，又回归最初的简单印象阶段。对索引学习来说，也同样会经历这个类似的过程，最后，对索引的应用达到炉火纯青的地步后，每次面对问题时，都能做到信手拈来，游刃有余，更主要的是，在很多场景中，仅仅通过索引技术的应用，瞬间就能解决看似非常棘手的大问题。

通过上面的论述，我们知道，索引在SQL调优中很重要，学起来也比较复杂，难以掌握，但熟练掌握后会很有用。这个世界上，没有哪种重要、复杂而特别有用的东西能在短期内被轻松获得，索引也是一样。关于索引的学习，这里不再啰嗦，仅通过一句话概括：对索引学习来说，只能在深刻理解索引组织结构和特性等理论的基础上，经过长期不断实践才能真正掌握。此时，可能有的读者会不高兴，心想：既然这样，你说了这么多不还是没用吗？你写这书还有什么意义呢？如果这样想，读者可能误会本人的意思了。因为，任何技术的学习，都涉及两个要素，一是正确的方向和路径，指出关键要点，并进行正确解析，保证学习者少走弯路，尽量不走弯路，否则，学习者可能因为方向不对或不能掌握和理解关键要点，多走很多弯路，浪费大量宝贵的时间、精力和金钱，甚至有人终其一生，水平和能力也难以达到较高境界，这种实例从古至今，各行各业中并非罕见。因工作原因，本人从上世纪90年代初就涉猎数据库领域，但限于不同时代多方面因素，从最初一个人的砥砺前行，到现在能对技术领域的明辨，一路走来，这期间的学习道路也并非平坦和笔直，曾几何时，也浪费过很多金钱、时间和精力，用于购买并彻夜研读实际并无太高价值的书籍资料，这，也是本书的初衷，那就是希望结合自己的经历和经验，尽一己之力为学习者提供一条捷径，让他们少走弯路，甚至不走弯路，从而把节省的时间、精力和金钱用于更有意义的事情；上面，我们论述了学习技术的第一个要素，那么，第二个呢？那就是学习者自己的努力，这个道理很容易懂，否则，如果学习者自己不努力，就算硬塞给他一本绝世秘籍，也难以大幅提升他的能力和水平。

上面强调了索引对SQL调优的重要性，也谈到了索引学习的正确路径和方法，接下来，我们这里再次强调，无论怎么讲、讲多少，也难以穷尽索引的应用方法和适用场景。索引应用的最高境界是能做到熟能生巧、活学活用，其使用方法并不是生搬硬套，所以，本书中案例除了给读者讲解具体场景的解决方法，更主要的是启发大家学习和掌握分析问题的思路、方法和步骤。鉴于以上论述，这里，我们仅从两个方面讲解和论述索引应用方面的内容，以期抛砖引玉。

有关索引的组织结构、分类及各自特性等相关内容，本书4.2节中都做了详尽介绍和论述，为了节省篇幅，此处不再赘述。下面，从索引应用的一般原则和索引应用的认识误区两个方面，来介绍和论述索引应用的相关话题，希望能对读者有所启发。

1.1. 索引应用的一般原则

1）索引越少越好

建索引时，需要从整个系统角度综合考虑，能少建就少建，能不建就不建。索引是把“双刃剑”，即使应用正确，也是在提升检索性能的同时，以牺牲数据写性能和增加系统负载为代价的。更何况，有索引的表比没索引的表数据加载效率会差很多。平时工作中，经常看到这样的开发环境，每个开发人员都可以建索引，觉得哪里应该建个索引，就建一个，日积月累，每张表上一大堆索引。这样的话，暂且不说研发人员建的索引合理不合理，就算合理，也缺乏系统整体上的统筹和兼顾，更何况很多时候，研发人员建的索引根本就用不到，等到产品上线，性能不好，负载也很重，没办法，再找人进行优化，现实中，这种场景还是比较常见的。

2）索引列越少越好

除了上面说的在表上随便乱建索引外，另一个经常遇到的场景就是，研发或其他人员由于不太懂SQL调优技术，干脆把where条件中的所有列都建上索引，不但增加了索引的数量，更主要的是，会出现很多大的复合索引，他们认为这下总算万无一失了，执行计划必须走索引，其实不然，这样的话，即使执行计划走索引，有时也不是最优的，甚至可能会导致很差的性能。很多时候，哪怕一个合理的单列索引，也比多个庞大的复合索引强很多，进而为相关SQL语句带来大幅的性能提升。

3）尽量少用函数索引

平时的优化工作中，在客户库里，常常会看到函数索引的身影，有的还比较多。函数索引的应用，很多时候是无奈之举，因为系统一旦上线，应用代码就不那么容易更改，即使更改，也需要一定的时间和周期，期间，只能用函数索引来解决发现的某类性能问题。因此，产品线的设计、研发和测试阶段都非常关键，除了这里讲到的函数索引，还有太多的事情都需要在这些阶段处理好。

4）选择正确的索引类型

关于索引类型，大家可以参考官方或其他相关文档。这里特别说明的是，B*Tree索引和位图（Bitmap）索引，在很多OLTP业务的库上，因为建立了不合适的位图索引而导致数据库故障，最后问到始作俑者，他们振振有词的说，因为这些索引列上基数低，建位图索引会提高性能。他们这点说的在有些场景是对的，但在OLTP环境，建位图索引还是需要谨慎，因为，除了在低基数列上它能降低索引大小和提升性能外，在修改数据时，它加锁的粒度也是比较大的，也许，位图索引更适用于低并发的OLAP业务。

5）为复合索引选择正确的列顺序

关于复合索引列顺序这个话题，其中涉及了太多的因素，除了索引结构本身，还会涉及到SQL语句、执行计划、谓词及数据环境等因素，这里不做赘述。大家只需记住一点，当必须建立一个包含多个列的复合索引时，尽量将使用频繁且选择性好的列排在前面。

6）为分区表选择正确的索引类型

关于分区表上的索引类型，各种类型的索引各有优劣，读者可以参考本书4.2节，也可参考官方或其他相关文档，进行对比研究，这里不再赘述。这里，需要说明的一点，现实中的分区表都是比较大的数据表，因此，除非特殊要求，本地索引还是比全局索引有更多的应用和优势。

1.2. 索引应用的认识误区

1）只有走索引才是最优的

不一定，要看具体的场景。

2）索引有益无害

不一定，索引尽量少建，因为索引是以牺牲写性能和负载为代价的。

3）索引肯定会比表小

不一定，现实中，索引和表差不多一样巨大，甚至比表还大的情况有时也能遇到，每当遇到这种情况，客户表现的很吃惊和诧异，其实，明白了索引的结构和原理，也就觉得没什么，这一般是乱建索引或索引长期疏于维护的结果。

4）索引输出的数据都有序

不一定，FFS操作输出的数据就无序。

5）索引高度会极大影响性能

理论上说，索引高度会影响索引的检索速度，现实中，除非高频率、高并发、大数据量检索，一般对性能的影响还是不太明显的，但还是要注意，记得定期监控和维护索引。

6）位图索引（Bitmap）会很小且很快

不一定，位图索引之所以比B*Tree索引占用空间小和检索速度快，那是因为对低基数列值进行了压缩处理，当位图索引列的基数比较高时，位图索引也会变得很庞大，这时，距离位图索引的适用场景也就渐行渐远了，或者说，这个位图索引就不该存在了。