SQL SERVER Performance 避免反向查询

作者:RiCo技术农场  发布日期:2012-07-15 11:29:42

当我知道某句SQL耗用大量成本且查询相当缓慢时,

表示我可能无法躲掉 SQL Tuning 苦工,

而第一步往往就是SARG格式改写,

SQL符合SARG格式可让查询语句利用索引快速搜寻资料(前提是你已有正确建立索引),

尽力改写SQL符合SARG格式永远是 SQL Tuning 中不可缺少又重要的环节(大部分sql tuning tools所达不到),

这篇我来测试一下為什麼要避免反向查询,因為反向查询佔绝大多数案例,

但对於开发人员来说多写几个字真的不会多花你几秒鐘时间,

而且还可以大幅改善你的SQL查询效能,何乐而不為呢....

 

查询需求: ReferenceOrderLineID 排除  0,1,2,3,5,9,15,19,24,28,32,40,44

 

大多数开发人员几乎会使用 not in (因為直觉也方便)

select TransactionDate,TransactionType,Quantity,ActualCost from production.TransactionHistory where ReferenceOrderLineID not in (0,1,2,3,5,9,15,19,24,28,32,40,44)

 


 

CPU和I/O 统计资料(logical reads:581)。

 


 


 

执行计画(cost:0.554)。

 

可以看到执行计画使用索引扫描作业,索引扫描作业资料列数目20931,

查询已有大海捞针的需求,但却使用索引扫描,这显然不太正常www.it165.net

下面是改写后的结果,你将看到反向操作的成本是相当昂贵且耗时的。

 

改写SQL

select TransactionDate,TransactionType,Quantity,ActualCost from production.TransactionHistory where (ReferenceOrderLineID >=4 and ReferenceOrderLineID <5)or (ReferenceOrderLineID >=6 and ReferenceOrderLineID<9)or (ReferenceOrderLineID >=10 and ReferenceOrderLineID<15)or (ReferenceOrderLineID >=16 and ReferenceOrderLineID<19)or (ReferenceOrderLineID >=20 and ReferenceOrderLineID<24)or (ReferenceOrderLineID >=25 and ReferenceOrderLineID<28)or (ReferenceOrderLineID >=29 and ReferenceOrderLineID<32)or (ReferenceOrderLineID >=33 and ReferenceOrderLineID<40)or (ReferenceOrderLineID >=41 and ReferenceOrderLineID<44)or (ReferenceOrderLineID >=45) 


 

CPU和I/O 统计资料(logical reads:145)。

 


 


 

执行计画(cost:0.104)。

 

或许有人还是不想改写那麼多,可能会问是否还有其他方法来处理,

当然是有的,你也可以利用提示(forceseek)来处理,

但查询效能的改善不会太多,

而且你的资料库版本要SQL2008以后才支援该资料表提示。

 

结论:

可以看到使用反向查询的成本相当昂贵且耗时,而且也无法真正利用索引改善效能,

这不但让你所建立的索引无三小路用,也浪费硬碟空间和记忆体(Buffer Pool)资源,

如果可以的话,请尽力将系统中所有非SARG SQL改写成符合SARG SQL,

因為任何资料库效能优化都不及调校一句高成本 SQL 所带来的效益。

Tag标签: Performance   反向查询  
  • 专题推荐

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