MSSQL 性能调优心得（三）

还是利用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值也一定要高。确实有点运气的成分，而且真的要敢于怀疑一切的精神。