這些指標是相互排斥的嗎？

我有一個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，非常詳細，建議和「強硬的愛」。 –

這些指標是相互排斥的嗎？

回答

相關問題