大概算是从13年8月份的项目开始接触oracle 的sql优化，当时如小白一般，只是道听途说过类似使用like之类的语句效率很差。由于工作压力大，每天逼迫着自己去学习，去读一条条sql的执行计划，也不断积累了一些oracle关于sql调优方面的理论知识，也从中知道了like效率到底差与不差的原因。在初学sql 调优的时候，调优sql都是着眼于这张表是不是走了全表扫描，这个索引走了skip的形式效率不高等问题，但是对于一些执行计划看起cost很低的sql，但实际执行起来就是很慢的情况，始终不能理解其原因。也是这时候，明白自己需要系统的学习oracle的CBO优化器，于是一本本的买了些相关书籍，其中个人觉得最好的还是《基于oracle的sql优化》，一篇篇细读后，对于sql调优的整体轮廓有了初步的认识，一些细节问题也能够注意到 了。比如统计信息的采集时间，是不是对临时表做了统计信息，表的联接方式是否合理，等等。。。
大概有半年多的时间，一些较为复杂的执行计划也能够理出个头绪来，这个时候学会了使用一些hint，并一发不可收拾的爱上hint。由于自己不是开发出身，没有多么高超的sql书写技巧，不敢对sql语句随便更改，生怕改后业务逻辑不对，被开发数落。学了些常用hint后，有点洋洋自得的味道了，想让oracle走hash join就走hash join，让它全表扫就全表扫。在这个盲目的阶段，可以处理一些由于oracle判断失误导致表联接方式不正确的SQL语句，多是一些大表，本应hash却走了nestloop，导致sql执行很慢。对于这些sql，我通常就是来个hint ： use_hash ，no_use_nl之类，往往也能够解决问题，但总觉得欠缺点什么。我类似强迫症般要求oracle这样那样，到底会怎么样呢？
时间在敲着键盘的日子里面悄然而逝，渐渐地遇到了一些不听hint指示的SQL语句，无论我加怎么样的hint，就是无法走出我理想的执行计划，表示很无奈。无奈之下，就想着去改写sql语句，让oracle自己去判断出我所认为的好的执行计划。接着发现。。。我对sql语句大眼对小眼，压根不会改，忽然觉得一个天天做着sql优化的家伙似乎写不了啥复杂的sql语句，呜呼哀哉！于是有意识的去学习一些sql语句的写法，像with as ，merge，标量子查询改写等，这几天倒是改写了几条复杂的，效率很可观。由于是在内网上，需要去客户那拷贝才能拿出来，日后再贴上来与人分享吧。
现在呢，对于sql调优的思路感觉上还是比较清晰的，看到一条sql语句，不论多么复杂，首先要确认它的统计信息没有问题，然后再去细读下执行计划。这个时候呢，需要对nestloop，hash join，merge join这三种主要的表联接方式能有个深刻的认识，熟知在何种情形下效率最高。最好要了解下业务，知道每张表在执行计划的各个步骤会有大概多少的数据量参与运算，以便自己能够准确的判断出走哪种表联接方式最为高效。当然，sql调优说大点讲，是个工程型性问题，有一系列的方法论来辅助我们，但并不意味着每个方法在调优的过程中都能用到。举个例子，有条insert语句，后面跟的是一条较为复杂的select语句，虽然数据量较大但个人感觉执行计划较好，结果速度却是很慢。对于“慢”，我是理解为它在等待什么，于是我查看下这条sql语句的等待事件，发现存在一些日志切换的等待事件，原来由于redo日志文件较小，但插入的数据量较大，导致日志切换较快，但dbwr跟不上日志切换的速度，继而出现日志切换不成功的情况，于是这条insert语句还需要等待日志切换成功来继续插入操作。。。。。
没啥思路的说了一堆，也是想为自己总结点当下的情况，现在的自己更喜欢去改写sql语句，以达到较为满意的运行效率。尤其是对于一些复杂的sql，要多看，细致的看，划分好层次，读懂实际的执行计划，找出慢在哪里，从而对症下药。
by killvoon
2015-03-20 是个多雨的春天
扫一扫
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
