2 SQL文二

存储过程写法

　 declare @date_from datetime
declare @date_to datetime

set @date_from='2008-9-1'
set @date_to='2008-9-16'

select CWB_No,fn_Clt_Datetime,acctId_guid,fn_OrigZone_Id,DestSZMCode,DestZone_Id,CWBType,fn_Clt_Dat etime,fn_cwbtype,
PayType,Payweight,StdPriceweight,StdFreight,IsCalculated,AFterDsctFreight,
SchgFreight,InvcFreight,Salesamount,SchgDetail,SchgFreight_Remarks
from OCS_TB_CWB
WHERE
fn_Clt_Datetime between @date_from and @date_to

速度也慢。第一次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_Dat etime,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出来的，而是靠良好的设计和管理管出来的。