1

我有一个正在尝试调整的 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])
4

1 回答 1

3

严格回答问题：

  1. TotalReceived、ExchangeRateTimeKey、MatterKey、BillingTypeKey、CurrencyKey、PersonKey、CompanyKey、OfficeKey、PracticeGroupKey、ProfitCenterKey、PersonnelTypeKey、RankKey

  2. TotalBilled、ExchangeRateTimeKey、MatterKey、BillingTypeKey、CurrencyKey、PersonKey、CompanyKey、OfficeKey、PracticeGroupKey、ProfitCenterKey、PersonnelTypeKey、RankKey

  3. TotalBilled、TotalReceived、MatterKey、BillingTypeKey、TransactionDateKey、BusinessProcessInstanceDateKey、PersonKey、CompanyKey、OfficeKey、PracticeGroupKey、ProfitCenterKey、PersonnelTypeKey、RankKey、BillableHoursBilled、BillableValueBilled、StandardValueBilled、HoursBilled

TotalReceived除了第一个字段（ vs TotalBilled）之外，索引 1 和 2 相同。索引 3 与 1 和 2 不同。理论上，需要的查询TotalBilled不被索引 2 覆盖，而需要的查询TotalReceive不被索引 1 覆盖。但都是理论上的。

没有人会考虑添加这 3 个索引。它们太宽了。优化器向您暗示的是，它真的非常希望FiscalPeriodKey成为聚集索引中最左边的键。在时间序列中，聚集键的最佳选择是时间键，因为时间序列最常用于查询时间范围。唉，对于 DW 事实表，时间只是查询维度之一，通常其他维度（例如地理、组织单位、产品系列）也用于查询。你只能选择一个作为 hte 聚集键。将覆盖索引方法推到极限以覆盖所有这些情况会导致数据量过大和写入性能不佳。最终，您会意识到自己使用了错误的工具来完成这项工作。

我建议您调查升级到columnstores。随着列式存储使用完全不同的方法并且查询受益于段消除，所有这些问题都将消失。当然，这至少需要 SQL Server 2012，并且推荐使用 SQL Server 2014 来更新列存储。

更可口的解决方案是硬着头皮部署一个 SSAS 多维数据集。MOLAP 在关系服务器根本没有答案（至少在列存储之前没有）的这类问题上蓬勃发展。

没有聚集键。“ID”是主键

我假设您的意思是“ID 是用作主键的身份，默认情况下是集群键”。如果你真的是说你有一个带有非集群主键的堆，ID那么......你应该得到你遇到的问题，而且更糟。

您面临的问题的常见解决方法（在业界以“索引临界点”的绰号而闻名）是利用 ID 和插入时间之间的相关性。存储特定时间范围的最小和最大 ID 的后备表用于限制聚集索引扫描。有关特定示例，请参阅一次性索引。但是相关性只存在于一个维度（时间），而不存在于其他 DW 维度，因此您回到与选择聚集索引时间键相同的问题。同样，SSAS 多维数据集或列存储更适合该任务。

于 2013-07-16T12:24:09.500 回答