数据库优化方法论－梁敬彬优化的思路.pptVIP

改进优化（首次优化） 这里又要再次利用到索引的原理，SQL1是利用到了索引一般比表小的多的特点，现在又是要利用啥呢？ 哦，利用索引的快速定位原理。假如我们在name列建了一个索引，而现在是利用了索引的快速检索原理。 索引有个最大的特点是有序排列，当表记录检索到dc等以d打头的记录后，ORACLE就停止遍历了！ 为啥，因为索引是有序的，当出现d打头的记录后，绝对后面不可能再出现c打头的记录了，因为我们是查询=cc的值，当然停住了。 随时停止检索相比遍历全表，明显是少做事和不做事，效率可以意料会提升不少。 需求与设计（再次优化1） 遇到疑问最重要要去如何分析？ begin select count(*) into v_cnt from t1 ; if v_cnt0 then …A逻辑…. else then …B逻辑….. End; 我来翻译一下这段需求： 获取t1 表的记录数，判断是否大于0，如果大于0走A逻辑，否则就走B逻辑。 因此代码就如上所示来实现了。真正的需求是这样吗？ 其实应该是这样的：只要T1表有记录就走A逻辑，否则走B逻辑。 首先应该想法去理解需求！ 分析过程果然有新发现！原来该SQL1在过程包中类似如下: 需求与设计（再次优化1） 这里我们马上联想到《小余买鱼4》 ，妈妈真正的需求其实是要做美味的晚餐，站在这个角度，完全可以用现成的其他菜来代替非常麻烦的买鱼经历，少做事甚至不做事而快速满足需求，提升效率。 两者有区别吗？其实区别还是很大的，前者可是强调获取记录数，我们是不是一定要遍历整个表得出一个记录数才知道是否大于0？ 真正需求的理解可以让我们这样实现，只要从T1表中成功获取到第一条记录，就可以停止检索了，表示该表有记录了，难道事实不是这样？ 因此原先的SQL1 从Select count(*) from t1; 被改造为： Select count(*) from t1 where rownum=1; 速度从1秒提升到0.01秒，几乎可以忽略不计了。 需求与设计（再次优化2） 对于SQL2,我查看了T2表，发现真有大量重复记录，怪不得需要用distinct来排重。 天啦，居然还有这回事！还有更神奇的，关于此处的order by ，居然是多余的，展现的几个字段的输出根本无需排序，没这需求！ 接下来思路很简单，即优化了源头程序（另外一个数据库包），保证插入t2表的数据再不会有重复记录，然后再把t2表记录进行删除重复记录的操作。 我很奇怪为什么会有重复记录，在问明开发设计人员后，我明白了，原来是源头程序有漏洞，导致t2表出现大量重复记录，现在所有应用只要涉及到访问t2表的，都需要增加distinct关键字来排重！ 资源利用（花絮） 读者还记得我说的T2表排除重复记录的事情吧，我当时提供了技术方案给维护人员，方案是新建一张表出来，提取不重复记录，然后把旧表替换了，大致思路如下： 首先建立新表 Create table t2_new nologging parallel 12 As select distinct * from t2 where …..; 停应用 Rename t2 to t2_bk Rename t2_new to t2; 补上t2表的相关索引，并将t2表的logging属性恢复。 资源利用（花絮） 我之前有提醒是要在业务不繁忙的时候操作，比如凌晨打补丁的时候顺道操作。因为我有写了parallel 12 ，表示要并行用到12个CPU，（当时生产仅有12个CPU）。 可惜的是维护人员自作主张，在大白天系统繁忙的时候执行了上述语句，结果导致12个CPU资源被这条create table t2_new的语句占据消耗着，引发生产系统短时间的压力繁忙，险些压垮了系统，好在该语句在5分钟内结束，未造成严重的影响。 资源利用（花絮） 应该是《小余买鱼3》吧。 恭喜你，答对了！ 让我们一起回想一下小余买鱼3的故事： 当然《小余买鱼2》却是会合理利用资源的典范，爸爸去出差了，要去那么远的地方，不选择开车去就是傻瓜了。 如果维护人员按我的要求在凌晨打补丁的时候顺便执行这个语句，不用并行也是不善于利用资源，因为凌晨系统没有什么进程在运行，不会有应用因为CPU被占用光而受到影响。 小余不会合理利