没有合适的资源?快使用搜索试试~ 我知道了~
本文作者通过身边的案例,详细阐述了SQL优化过程中的种种方法和小窍门,内容丰富且言之有物,希望能让接触到SQL的同学可以体会到SQL提速的乐趣!关于SQL优化,前辈们、技术大咖们、各个技术论坛上早就有很多的优秀文章,今番我再次提起,心情忐忑,实在是有些班门弄斧和自不量力了。在大家的鼓励下我想写一下也好,就写我们身边的事,用身边的案例来演绎SQL优化,用形象语言把SQL优化说成我们身边的事,希望能让接触到SQL的同学可以体会到SQL提速的乐趣!提到SQL优化,我们不得不学习几个名词,这就好比武侠小说里练习武功一样,不知道几个穴道,不了解几个气门都不好意思提自己是练功夫的。名词挺多,除了这里提到的
资源推荐
资源详情
资源评论




















SQL优化之六脉神剑优化之六脉神剑
本文作者通过身边的案例,详细阐述了SQL优化过程中的种种方法和小窍门,内容丰富且言之有物,希望能让接触到SQL的同
学可以体会到SQL提速的乐趣!
1.前言
关于SQL优化,前辈们、技术大咖们、各个技术论坛上早就有很多的优秀文章,今番我再次提起,心情忐忑,实在是有些班门
弄斧和自不量力了。
在大家的鼓励下我想写一下也好,就写我们身边的事,用身边的案例来演绎SQL优化,用形象语言把SQL优化说成我们身边的
事,希望能让接触到SQL的同学可以体会到SQL提速的乐趣!
2.理解几个名词
提到SQL优化,我们不得不学习几个名词,这就好比武侠小说里练习武功一样,不知道几个穴道,不了解几个气门都不好意思
提自己是练功夫的。名词挺多,除了这里提到的还有好多,比如内外连接、嵌套循环、游标共享、绑定变量、软硬解析等等,
武功太多,练不过来,那我们先把马步扎好再说。没有提到的功夫在藏经阁都有,请按需百度。
2.1 执行计划
执行计划是什么呢?就是SQL执行的路径和执行步骤。怎么理解呢?你从家里到公司可以选择开车走高速,也可以选择做公交
车走市区街道,那么你选择用哪个交通工具,走哪个路线,就是你的执行计划。但是一次只能有一个方案。
一个SQL生成了执行计划,他就会被固定到共享池里,只有在表发生了变更、统计信息过旧、共享池被刷新、数据库重启等情
况下SQL才会重新生成执行计划。还是从家到公司,城市在修路,公交路线变化都会影响你选择什么样的方式上班。
2.2 索引
索引是一个单独的、物理的数据库结构,它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻
辑指针清单。怎么理解呢?表是一本书,索引就是这本书的目录。
2.3 统计信息
统计信息主要是描述数据库中表,索引的大小、规模、数据分布状况等的一类信息。比如表的行数、块数、平均每行的大小、
索引的leaf blocks、索引字段的行数、不同值的大小等,都属于统计信息。
Oracle的基于成本的优化器(还有一种是基于规则的,武功过时了,不练了)正是根据这些统计信息数据,计算出不同访问路
径下,不同连接方式下,各种计划的成本,最后选择出成本最小的计划。如果没有统计信息呢?会发生动态采样,就是在生产
执行计划前去表、索引去进行数据采样。
怎么理解呢?还是从家到公司,有了地图和公交信息,高速收费情况等信息,大家就可以选择最合适的上班方案了。没有这些
现成的信息你就需要实际去调研一下了,比较麻烦,而且可能造成不合适的选择。
3.某个SQL是否能优化?
怎么能确定一个SQL是否能优化呢?这个不太好回答,DBA们经常说先分析分析看看。那么分析什么呢:现在效率如何?执
行计划?跑的时候等待事件?表多大?选择列上有无索引?选择性如何?有统计信息?连接方式?......又是这些名词,还没有
完全理解的小伙伴不要着急,我不是卖野药的,马上就要表演啦!
其实呢,也可以不用这么复杂。一个非常劣质的SQL(跑几十分钟,甚至是几个小时的SQL)最终能不能有质的提速,主要就
是看业务的本质上需要访问多少数据量,如果业务本质上需要访问的数据量越少,一般来讲提速余地就越大。简单吧,所以一
个业务专家,你遇到了一个劣质SQL,不用DBA分析,你应该就知道有没有优化余地了。

怎么理解呢?一个大操场上有一个红色的玻璃球,让你去拿到,你没看见,地毯式的找半天,有人给你个坐标图,你10秒钟
跑过去就找到了,这就是有提速余地,如果满操场上都是需要的红色玻璃球让你拿,无论怎么拿,都要拿半天,这就是没法有
质的飞跃(就是没办法几秒钟、几分钟把活干完)。
下面我们循序渐进的讲一些案例吧。
1.1利用索引提高效率
INS_USER_571 表上有两个索引IDX_INS_USER1_571,IDX_INS_USER2_571分别对应列BILL_ID,
EXPIRE_DATE列,SQL 和执行计划:
select * from SO1.INS_USER_571 M where M.BILL_ID = '13905710000' and M.EXPIRE_DATE > sysdate;
符合BILL_ID的数据只有一条,而符合EXPIRE_DATE条件的数据有几万条,就是说BILL_ID选择性好,选择
IDX_INS_USER1_571索引就会更快的找到这条数据。
怎么理解?大操场上找1个玻璃球,给你两个坐标图,一张直接告诉你这个玻璃球的具体位置,一张图告诉你在某个10米的范
围圈内,选择哪个呢?肯定选第一张。
1.2走索引反而慢?
在CREATE_DATE上建立个索引IDX_INS_USER4_571:
SQL:
PLAN:没有走索引?!
难道是优化器有问题?测试下就知道了。为了明确加Hints测试:

看来优化器没有错!
当需要扫描的数据量较大时,走索引的成本比全表扫描的成本还要高。
怎么理解?一本书1000页,其中800页的内容都是你需要的,那你看书的时候就没有必要每看一页都要回过头来翻翻目录了,
这样多罗嗦呀!直接顺序往下读好了。
1.3本招的几个口诀
在where条件中选择列上加了函数,没法利用索引
例如:where to_char(create_date,’YYYY-MM-DD HH24:MI:SS’)>= ‘2015-04-08 00:00:00’
这样没法利用到create_date的索引
正确的写法:
where create_date>=to_date( ‘2015-04-08 00:00:00’,’YYYY-MM-DD HH24:MI:SS’)
1. 变量类型要正确,避免隐式转换造成没法利用索引
Bill_Id 是varchar2的类型
Where bill_id=1 就没法利用索引。
2.Where条件终须用到前导列才能走上组合索引,组合索引中选择性好的要放在前面:
索引ind_ins_user5_571(create_date, cust_type): where cust_type =1
只有cust_type这个条件,而没有create_date走不上索引ind_ins_user5_571
3.在多表关联的情况下,即使表很小,在关联字段上加索引往往都非常有效,可能影响表的连接方式而节约成本。
4.不要试图每一个字段上都加索引,索引越多对表的DML影响越大,对DML要求很高的接口表都不建议加索引,组合索引的
列越多,索引树可能越深,有时候不但不能查询提速,反而还影响了DML效率。
例如:Where条件中有一个选择性非常好的字段,如BILL_ID/ACC_ID/USER_ID,其他选择条件如STATE/TYPE没有必要再
进行组合索引。
1.4老板再也不用担心我的数据积压啦
某报表库下有这样一条sql,每个地市启动了10个线程,去进行数据处理,每个地市执行频率每小时高达几万次,造成数据库
CPU压力巨大,而降低线程又会出现数据积压,咋整呢?DBA们也捉急呀!
剩余16页未读,继续阅读
资源评论


weixin_38677227
- 粉丝: 4
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助


最新资源
- 新时代背景下数据科学与大数据专业人才培养的若干思考.docx
- IntelVT概述-X概述-虚拟化.docx
- AAGUI-C语言资源
- D-Petro软件在油田标准化设计中的应用.docx
- 建设工程项目管理(B卷).doc
- IBM-V3700实施手册.pdf
- 关于市政工程项目管理问题及优化策略.docx
- SDH数字微波接力通信系统项目可行性报告.docx
- TSL8899PLC变频供水控制器说明书.doc
- GAndroid软件工程师.doc
- 基于GSM网络汽车报警系统设计.doc
- 物联网中的智能环保感知技术.docx
- 中国互联网糖尿病人群白皮书.pdf
- J2Cache-Java资源
- 绩效评价中的数据采集和社会调查.ppt
- 互联网农业行业分析报告.docx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈



安全验证
文档复制为VIP权益,开通VIP直接复制
