我已经问过几乎相同的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秒钟。 。
在第一种情况显然影响最大的是由[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]
灿有人指出我可能的原因和解决方案?
您能分享XML执行计划吗?右键单击exec计划图形表示的背景,然后从弹出菜单中选择“将执行计划另存为...”并将其保存到sqlplan扩展名的文件中。这是一个普通的XML文件,您可以在记事本中打开它,sqlplan扩展只是将它与SSMS相关联。然后将其上传到Dropbox,sky/onedrive或类似的并共享。否则,我们只能猜测发生了什么。 – dean
我的猜测是减速来自嵌套循环。尝试更新统计信息,也许强制一些HASH JOIN,看看它是否有帮助。 – adrianm