2014-04-02 31 views
2

我已经问过几乎相同的question,但它没有得到满意的回答,我只是出现了类似的情况。> =运算符在where子句中的巨大影响

select r.order_number, cl.COMMANDE, m.[order #] 
from [Offline RN General] r 
left join mcdb_summary m ON r.order_number=m.[order #] 
left join coclico cl ON cl.ORDER_ID=r.order_number 
where r.[order_number] is not null and r.GroupID=358472 and converted='yes' and r.[Booking Date]>='20140401' 

所以最后一个条件(的。R [预订日期] > =“20140401”)导致查询采取至少40秒内完成,而没有一个条件或 - 怪异 - 或者如果它是r。[预订日期] <'20140401'只需要2秒钟。 。 greater or equal less than

在第一种情况显然影响最大的是由[mcdb_summary]发[suggested2]索引扫描 - 这是以前由SSMS建议 - 这里是它的定义:

CREATE NONCLUSTERED INDEX [suggested2] ON [dbo].[mcdb_summary] 
(
    [cancelled] ASC 
) 
INCLUDE ([order #], 
[Product_Name]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 

灿有人指出我可能的原因和解决方案?

+0

您能分享XML执行计划吗?右键单击exec计划图形表示的背景,然后从弹出菜单中选择“将执行计划另存为...”并将其保存到sqlplan扩展名的文件中。这是一个普通的XML文件,您可以在记事本中打开它,sqlplan扩展只是将它与SSMS相关联。然后将其上传到Dropbox,sky/onedrive或类似的并共享。否则,我们只能猜测发生了什么。 – dean

+0

我的猜测是减速来自嵌套循环。尝试更新统计信息,也许强制一些HASH JOIN,看看它是否有帮助。 – adrianm

回答

1

首先要尝试:

UPDATE STATISTICS [Offline RN General]; 

统计提供有关数据的分布信息(例如,有多少行日期X,多少日期Y,等等),这有助于查询引擎采取“成本根据”决定:执行索引查找,而不是索引扫描等

您可以通过运行一个简单的SQL query看到那些statististics:

DBCC SHOW_STATISTICS('<tablename>', '<indexname>'); 

你可以阅读更多关于何时统计are updated

+0

hmm,因为[Offline RN General]是一个视图,我在底层表(UPDATE STATISTICS Offline_RN;)上执行了命令,并且它实现了诀窍! 我会做一些测试,并标记你的答案是正确的。为什么一张表的统计数据对查询有如此大的影响?我虽然我的指标错了。不管怎么说,还是要谢谢你! – Maju

+0

不客气。 –

+0

好吧,这里是执行计划后更新统计 https://drive.google.com/file/d/0B4L60aY5Y92GSzEyaGY5MmZOaTg/edit?usp=sharing 我不明白为什么我不得不手动执行更新,而sp_autostats显示表格的自动恒定器开启 – Maju

0

在没有看到索引的情况下,我会确保所有可能的键都能够很好地优化“R”表上的查询。

table     index 
[Offline RN General] (groupID, converted, order_number, [booking date] ) 
mcdb_summary   ([order #]) 
coclico    (order_id, commande) 

而且,所有的列(转换)的确认应是合格表......我只能猜测,转换后处于离线RN总表。

相关问题