上文说道了失效效应。只想说明在Performance Tunning方面只能根据情况来寻求原因并解决。这是一个有意思的过程。大原则是经验，帮助我们少犯错误。因此，糟糕的设计，必然导致性能问题。没有经验的程序员必然会写出糟糕的代码。但是良好的设计可以弥补程序员的经验不足。这个到此打住，这个topic涉及品质管理，实在太大了。

　　再看一例，失效效应的体现。

　　还是上文数说道了2种SQL文写法产生的执行计划。我选用一台双核的PC，相当于2个单核CPU。

　　有一个大表TB_CWB。记录约30-40万。（在生产环境下属于小数据量，在我的测试中可以看成大表）。表上已经对fn_Clt_Datetime 做了索引。

　　1.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
　　WHERE
　　fn_Clt_Datetime between '2008-9-1' and '2008-9-16'

　　运行结果，发现奇慢无比。需要12秒才能出结果。

　　检查执行计划，发现用了聚集索引扫描（主键），就是相当于选择了全表扫描的计划。因为CBO认为这句SQL比动用索引还要快。见下图

　　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_Datetime,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