SQL SERVER Performance 善用Fast N Hints

作者:RiCo技術農場  发布日期:2012-07-13 11:52:48

我想大家都应该知道,如果查询特性针对 Nonclustered Index有排序需求的话,

那麼你在设计该 Index 时就该考虑排序需求,

虽然尽量避免针对 Nonclustered Index排序(clustered Index存在逻辑排序较适合),

因為针对大型资料表进行排序操作将耗费大量系统资源(tempdb 和整体时间),

但现实世界中这是相当难避免的,昨天我处理一个大型成本查询效能问题,

经过SQL Tuning 后查询成本改善约150倍、整体时间改善约3倍,

而我个人觉得任何资料库优化效益都不及调校一句高成本SQL来的高,

下面我大概模拟一下。

 

select LogDate,LoginId,LogMessage,LogLevelfrom dbo.ap_log where LoginId in('sherry','papa','rico') order by LoginId

我先针对查询SQL特性建立Nonclustered Index并考虑排序,然后执行该查询。

 


 

整体时间(ms):281+8253=8534。logical reads:12824。

 

 
 

整体查询成本:7.299。


执行计画中看到虽然查询有正确使用索引搜寻资料,

但我改写SQL后(使用 fast 1 hints) ,更进一步降低查询成本和时间。


改写SQL加入option(fast 1)

select LogDate,LoginId,LogMessage,LogLevelfrom dbo.ap_log where LoginId in('sherry','papa','rico') order by LoginIdoption(fast 1)



 

整体时间(ms):313+7559=7872。logical reads:12824。

  
 

整体查询成本:0.003。

可以看到索引搜寻作业估计的资料列数目=1,

透过更改基数来改善查询最佳化整体成本。

 

结论:

可以看到整体查询成本改善 2433 倍,整体时间改善约1.08倍,

如果查询特性资料量大的话www.it165.net

强烈建议加上option(fast 1) 提示改善整体查询成本并减少回覆时间。

 

Tag标签: SQL   SERVER   Performance  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规