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)会很小且很快文章来源:https://www.toymoban.com/news/detail-473061.html
不一定,位图索引之所以比B*Tree索引占用空间小和检索速度快,那是因为对低基数列值进行了压缩处理,当位图索引列的基数比较高时,位图索引也会变得很庞大,这时,距离位图索引的适用场景也就渐行渐远了,或者说,这个位图索引就不该存在了。文章来源地址https://www.toymoban.com/news/detail-473061.html
到了这里,关于解决Oracle SQL语句性能问题——合理使用索引的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!