对SQL Server上的DISTINCT执行大规模性能惩罚的变通办法？

当我发送以下查询到我们的数据库

，则返回<2秒4636行：对SQL Server上的DISTINCT执行大规模性能惩罚的变通办法？

select 
    company3_.Un_ID as col_0_0_ 
from 
    MNT_Equipments equip 
inner join 
    DynamicProperties dprops 
     on equip.propertiesId=dprops.id 
inner join 
    DynamicPropertiesValue dvalues 
     on dprops.id=dvalues.dynamicPropertiesId 
inner join 
    Companies company3_ 
     on dvalues.companyId=COMPANY.Un_ID 
where 
    equip.discriminator='9000' 
    and equip.active=1 
    and dvalues.propertyName='Eigentuemer'

但是当我添加不同的SELECT子句，它需要近45分钟，归还剩余40项。这似乎有点不成比例 - 我能做些什么来改善这种情况，解决这个问题或者至少弄清楚这里究竟发生了什么？

执行计划

没有明显

Plan 1

具有鲜明

Plan 2

你的帮助是非常感谢！

来源

2012-04-10 Myles_TR

请将执行计划上传到＆，不要区分到外部站点 - 例如imgur.com。或者可能将XML计划上传到我们可以看到它们的地方。 – 2012-04-10 10:52:06

[这是专辑]（http://imgur.com/a/W8VfL） – 2012-04-10 11:06:32

也许是一个分组子句更好的选择，因为你只选择一列？ – 2012-04-10 11:07:08

聚簇索引扫描表明在查询的表上没有好的索引。如果您创建以下索引，则应该改进执行时间。

CREATE NONCLUSTERED INDEX [IX_MNT_Equipments_Active] ON [MNT_Equipments] 
(
    [propertiesId] ASC, 
    [discriminator] ASC, 
    [active] ASC 
) 
GO 

CREATE NONCLUSTERED INDEX [IX_DynamicPropertiesValue_Name] ON [DynamicPropertiesValue] 
(
    [propertyName] ASC 
) 
GO

来源

2012-04-10 13:00:37 Wim

作为一般的观点，这是真的，它可能会导致生成一个新的计划，以避免这个问题，但同样适用于没有'DISTINCT'的查询。有一个基数估计问题。 – 2012-04-10 13:04:00

没有索引SQL Server根据子查询的预期返回行进行猜测，最好的查询计划是什么，在这种情况下，distinct的查询计划非常糟糕。创建索引将帮助SQL服务器做出更好的决定。 – Wim 2012-04-10 13:28:15

我并不是说OP不需要额外的索引，但他们仍然可能会得到一个次优的计划，因为它没有深入到为什么连接的估计是错误的。 – 2012-04-10 13:33:22

对SQL Server上的DISTINCT执行大规模性能惩罚的变通办法？

回答

相关问题