SQL Server性能调优杂记（二）－－－－傻瓜机的失效效应续

核心提示： 速度也慢，第一次16秒（比全表扫描还慢?有可能），SQL Server性能调优杂记（二）－－－－傻瓜机的失效效应续(2)，第二次9秒，这还像点话，是出现性能问题的根本原因，好的品质不是靠测试和后期强人tunning出来的，但是上面SQL文一再执行一遍，也差不多9秒

速度也慢。第一次16秒（比全表扫描还慢?有可能），第二次9秒，这还像点话。但是上面SQL文一再执行一遍，也差不多9秒。

说明这2种写法在这里情况下大致都差不多。

第2种写法的执行计划。非常肯定用到了索引。在这里我基本倾向于涉及查询之类的，用存储过程，CBO失效认为全表扫描比索引代价小的可能性低。

3 SQL文三

对于SQL文一，强制用索引。

--检查价格计算结果

select CWB_No,fn_Clt_Datetime,acctId_guid,fn_OrigZone_Id,DestSZMCode,DestZone_Id,CWBType,fn_Clt_Datetime,fn_cwbtype,
PayType,Payweight,StdPriceweight,StdFreight,IsCalculated,AFterDsctFreight,
SchgFreight,InvcFreight,Salesamount,SchgDetail,SchgFreight_Remarks
from OCS_TB_CWB
WITH (index(IND_FN_CLT_DATETIME_OF_OCS_TB_CWB))
WHERE
fn_Clt_Datetime between '2008-9-1' and '2008-9-16'

运行0秒，天哪，不会吧。赶快看执行计划

执行计划不经用了索引，还动用了并行装载数据。为了公平期间，反复运行几次，最慢4秒，基本1秒。

在这个案例中。指定值的SQL在CBO看来还不如全表扫描（估计因为是它已经知道你要找的值，根据数据分布，发现摸一次索引树的代价还不如全表扫描更快）。呵呵，但是你强制指定索引，它决定把2个cpu都用上来帮助你获得最佳性能。

结果成了在这个case中的最佳结果。

不过，在大部分情况下，我个人认为SP的写法还是比较好的选择。parse参数的方法（sp_executesql）只有当只变化参数值，可以重用第一次的执行计划。但是并一定说SQL Server给你的执行计划就是好的。

总结一下，

1)这个case告诉我们，你建了索引也不会快，因为SQL Server的CBO会决定不用，这还是和SQL文有关系。

2)硬件强也要看SQL Server是不是考虑用Paralism,而不好的SQL文反而会让CBO的失效效应出现差的结果。

3)而最后一个case，但是有点对失效效应的利用的意味，让你把硬件充分发挥出来，倒是有点出奇制胜的效果了。

4)回到正题，良好的设计和代码控制，才是性能好的根本保证。而有很多项目组很忽视数据库设计review和代码review，是出现性能问题的根本原因。好的品质不是靠测试和后期强人tunning出来的，而是靠良好的设计和管理管出来的。