这些指标是相互排斥的吗？

我有一个SQL 2008数据库，我正试图调整，并且使用了一些我发现的用于从SQL数据管理视图中生成推荐索引的示例。这些指标是相互排斥的吗？

在几种情况下，我看到建议使用多个索引，并且这些索引具有相同的定义，直到INCLUDE部分为止，此时它们有一些不同的列。

我知道我不应该只是创建一个脚本从互联网上建立的每一个索引，但除此之外，如果我确实创建了所有这些，那么引擎会根据情况使用这些索引中的每一个，或者将两个他们没有使用？

CREATE INDEX [IX_FactBilling_FiscalPeriodKey1] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalReceived], [ExchangeRateTimeKey], [MatterKey], [BillingTypeKey] 
, [CurrencyKey], [PersonKey], [CompanyKey], [OfficeKey], [PracticeGroupKey], 
[ProfitCenterKey], [PersonnelTypeKey], [RankKey]) 

CREATE INDEX [IX_FactBilling_FiscalPeriodKey2] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalBilled], [ExchangeRateTimeKey], [MatterKey], [BillingTypeKey], 
[CurrencyKey], [PersonKey], [CompanyKey], [OfficeKey], [PracticeGroupKey], 
[ProfitCenterKey], [PersonnelTypeKey], [RankKey]) 

CREATE INDEX [IX_FactBilling_FiscalPeriodKey3] 
    ON [ClearViewDev].[Performance].[FactBilling] ([fiscalperiodkey]) 
    include ([TotalBilled], [TotalReceived], [MatterKey], [BillingTypeKey], 
[TransactionDateKey], [BusinessProcessInstanceDateKey], [PersonKey], 
[CompanyKey], [OfficeKey], [PracticeGroupKey], [ProfitCenterKey], 
[PersonnelTypeKey], [RankKey], [BillableHoursBilled], [BillableValueBilled], 
[StandardValueBilled], [HoursBilled])

来源

2013-07-16 Kevin Buchan

'FactBilling'上的聚簇索引键是什么？ –

没有集群密钥。 “ID”是主键。 –

那么，'ID'是一个非集群主键？ –

要严格回答这个问题：

TotalReceived，ExchangeRateTimeKey，MatterKey，BillingTypeKey，CurrencyKey，PersonKey，CompanyKey，OfficeKey，PracticeGroupKey，ProfitCenterKey，PersonnelTypeKey，RankKey
TotalBilled， ExchangeRateTimeKey，MatterKey，BillingTypeKey，CurrencyKey，PersonKey，CompanyKey，OfficeKey，PracticeGroupKey，ProfitCenterKey，PersonnelTypeKey，RankKey
TotalBilled，TotalReceived，MatterKey，BillingTypeKey，TransactionDateKey，BusinessProcessInstanceDateKey，PersonKey，CompanyKey，OfficeKey，PracticeGroupKey，ProfitCenterKey，PersonnelTypeKey，RankKey，BillableHoursBilled，BillableValueBilled，StandardValueBilled，HoursBilled

索引1和2是除了同一第一场（TotalReceived vs TotalBilled）。索引3与1和2不同。理论上，需要TotalBilled的查询未包含在索引2中，而需要TotalReceive的查询未包含在索引1中。但都是理论上的。

没有人在正确的心态会考虑添加这3个指数。他们太宽了。优化器暗示给你的是它真的非常像FiscalPeriodKey是聚簇索引中最左边的键。在时间序列中，群集密钥的最佳选择是时间密钥，因为时间序列最经常查询时间范围。唉，使用DW事实表的时间只有一个的查询维度，通常其他维度（例如地理，组织单位，产品系列）也用于查询。而你只能挑选一个作为聚集键。将覆盖索引方法推到极限以涵盖所有这些情况会导致巨大的数据容量膨胀和较差的写入性能。最终，你面临着认识到你正在使用错误的工具来完成这项工作。

我建议你调查升级到columnstores。所有这些问题都会消失，因为列式存储采用了完全不同的方法，查询受益于segment elimination。当然，这个至少需要SQL Server 2012，并推荐SQL Server 2014用于updatable columnstores。

更可口的解决方案是咬住子弹并部署SSAS多维数据集。 MOLAP在关系服务器根本没有答案的情况下（至少在列存储之前不存在）遇到这类问题。

没有集群密钥。“ID”是主键

我会假设你的意思是'ID是一个身份作为主键，默认情况下是聚簇键'。如果你确实意味着你有一堆非主群集的主键，那么..你应该得到你遇到的问题，并且更糟。

针对您遇到的问题（在业界众所周知的'index tipping point'名称下）的常用解决方法是利用ID和插入时间之间的关联。存储特定时间范围的最小和最大ID的后备表用于限制聚簇索引扫描。有关具体示例，请参见Disposable Indexes。但相关性仅存在于一个维度（时间）中，而不是其他维度维度，因此您回到选择聚簇索引时间关键字的相同问题。同样，SSAS多维数据集或列存储更适合于该任务。

来源

2013-07-16 12:24:09

“如果你确实意味着你有一堆非主群集的ID，那么......你应该得到的问题更加严重。”大声笑。谢谢你，Remus，非常详细，建议和“强硬的爱”。 –

这些指标是相互排斥的吗？

回答

相关问题