MSSQL 性能调优心得(三)
2009-02-24 17:35
246 查看
还是利用set statistics io/time on来协助分析磁盘和CPU的负载情况。
我们注意到有句SQL语句调用一个视图,逻辑读数值很高。形如 select c1,c2,c3.... from v1 where SomeID = 'abcd' and .......
v1又由很大的表t1,t2以及几个小表inner join而成的。根据参与join的表尽可能小的原则,我们尝试把视图改成表函数。正好SomeID上建有一个单独的索引,所以可以先行通过t1.SomeID找到需要的数据放到一个表变量中,再与其它表进行inner join。效果显著,逻辑读从几万一下子降低到几百。当然也需要稍微修改一下程序,变成 select c1,c2,c3.... from f_v1('abcd') where .......
还有一个查询语句的where用了or条件。由于逻辑比较简单,因此拆分成两个可以充分利用索引的select后再union all,也取得了非常好的效果。类似的还有IN,尽可能的用Exists来代替。
还有一种很常见的情况,where ExecDate >= '起始日期' AND ExecDate < '终止日期'。这样也可能会造成逻辑读狂高。如果只要 >= 就没这个问题。因此如果终止日期就是当前时间点,还不如不要这个条件。当然这个也不是绝对的,跟执行计划当时选择的索引也很有关系。
某些场景下甚至还需要“说废话”来优化。比如故意增加一个 日期 > '明显是废话的日期值' 的条件让执行计划更好的利用索引来减少表扫描和逻辑读。
余下的就是代码设计的问题了。比如看到了一个存储过程,有一个被关联的小字典表却逻辑读狂高。仔细分析发现在中间步骤做几个大表连接时也带上了这个小表,其实完全没必要,只要在最后输出时将代码翻译成中文即可。按照这个思路修改了代码,果然又降了很多。
还有的程序员在循环体里建立撤销数据库连接,这个也不是很好,如果将数据库连接作为一个参数传给调用的函数却是一个可行的改进方案。
SQL性能调优确实比较麻烦,除了思路要宽广之外,不得不承认,RP值也一定要高。确实有点运气的成分,而且真的要敢于怀疑一切的精神。
我们注意到有句SQL语句调用一个视图,逻辑读数值很高。形如 select c1,c2,c3.... from v1 where SomeID = 'abcd' and .......
v1又由很大的表t1,t2以及几个小表inner join而成的。根据参与join的表尽可能小的原则,我们尝试把视图改成表函数。正好SomeID上建有一个单独的索引,所以可以先行通过t1.SomeID找到需要的数据放到一个表变量中,再与其它表进行inner join。效果显著,逻辑读从几万一下子降低到几百。当然也需要稍微修改一下程序,变成 select c1,c2,c3.... from f_v1('abcd') where .......
还有一个查询语句的where用了or条件。由于逻辑比较简单,因此拆分成两个可以充分利用索引的select后再union all,也取得了非常好的效果。类似的还有IN,尽可能的用Exists来代替。
还有一种很常见的情况,where ExecDate >= '起始日期' AND ExecDate < '终止日期'。这样也可能会造成逻辑读狂高。如果只要 >= 就没这个问题。因此如果终止日期就是当前时间点,还不如不要这个条件。当然这个也不是绝对的,跟执行计划当时选择的索引也很有关系。
某些场景下甚至还需要“说废话”来优化。比如故意增加一个 日期 > '明显是废话的日期值' 的条件让执行计划更好的利用索引来减少表扫描和逻辑读。
余下的就是代码设计的问题了。比如看到了一个存储过程,有一个被关联的小字典表却逻辑读狂高。仔细分析发现在中间步骤做几个大表连接时也带上了这个小表,其实完全没必要,只要在最后输出时将代码翻译成中文即可。按照这个思路修改了代码,果然又降了很多。
还有的程序员在循环体里建立撤销数据库连接,这个也不是很好,如果将数据库连接作为一个参数传给调用的函数却是一个可行的改进方案。
SQL性能调优确实比较麻烦,除了思路要宽广之外,不得不承认,RP值也一定要高。确实有点运气的成分,而且真的要敢于怀疑一切的精神。
相关文章推荐
- MSSQL 性能调优心得(一)
- MSSQL 性能调优心得(二)
- 关于数据库性能调优心得
- 系统性能调优(6)----寻找性能瓶颈心得
- Oracle 性能调优心得
- Oracle性能调优实践中的几点心得
- Oracle性能调优实践中的几点心得
- Hibernate性能调优心得
- Oracle性能调优实践中的几点心得
- Oracle性能调优实践中的几点心得
- Spark性能调优之——JVM调优之原理概述 以及降低cache操作的内存占比
- oracle性能调优-虚拟索引
- MySQL的性能调优工具:比mysqlreport更方便的tuning-primer.sh
- 大数据性能调优之HBase的RowKey设计
- Spark性能优化:资源调优篇(转)
- CDH5 Solr性能调优
- 性能分析与调优的原理
- MYSQL数据库性能调优之七:其他(读写分离、分表等)
- 实习心得(二)--关于段错误,内存泄露,性能瓶颈
- 心得总结:Java性能优化技巧集锦2