非唯一鍵上的sql server聚簇索引

Question

我們有一個非常大的數據庫，並且使用了我們想要遠離的碎片。每當表格變得非常大時，我們就開始創建一個與前一個表格具有相同模式的新表格，並在另一個表格中保留一個數字，以幫助我們找到數據所在的表格。這是一個繁瑣的手動過程，意味着我們有數據分佈在N個不同的表格上，並且都具有相同的模式。

我們嘗試的想法是通過使用索引來消除對分片的需求。我們的數據查詢查詢不使用唯一鍵，並且許多記錄在列之間返回值相同。

以下說明了我們對特定表格的許多查找選擇，帶*的字段表示該字段可能會或可能不會被選中。

where子句：scheduled_test，*腳本，*標籤，* ERROR_MESSAGE

組/順序：messenger_id，時間片，腳本標籤，ERROR_MESSAGE，step_sequence，* adapter_type

我的想法是，我不會想要創建一個包含所有這11個字段的索引。我選擇了其中3個似乎更常用的包括總是在where子句中的那個。我已經讀過，建議不要有太多的領域太寬的索引。我也聽說優化器將首先使用索引字段，即使MSDN聲明唯一索引是最大優勢，但擁有非唯一索引並不少見。這不僅僅是我們的數據設計。我意識到SQL會向索引添加一些東西來使其具有獨特性，但這對我們的目的似乎並不重要。

當我查看與我們可能運行的查詢類似的SQL Server管理工作室的執行計劃時，它說「聚集索引查找成本100％」，但它使用我創建的聚集索引我希望這比只是生成的主鍵的默認聚簇索引（以前如何定義表）更好。我希望我在這裏擁有的和我們的分片方法一樣好或者更好，並且會消除對分片的需求。

我們一次將大量數據插入表中，但這些行在許多列中都有相同的數據值，我認爲他們甚至會傾向於在最後插入數據。這些插入不會與較舊的數據共享值，如果索引只是3列，希望這對插入不會造成太大打擊。

我說的話看起來是否合理，還有什麼我應該考慮或考慮的？非常感謝，我對這些類型的索引問題並不熟悉，但一直在各種網站上進行查看和試驗。

Answer 1

通常，聚簇索引越窄越好，因爲聚簇索引的聚簇鍵將被添加到所有非聚簇索引中，使得它們效率較低。

SQL服務器會爲非唯一聚簇索引添加一個唯一值，使它們（以及所有非聚簇索引）仍然更寬。

如果這些索引使用的空間對您來說不是問題，那麼您應該考慮聚集索引鍵的值是否不斷增加（或減少），就好像它不是，您將得到頁面拆分和碎片，肯定會傷害你的插入。

如果您可以檢查不同索引策略對普通查詢的影響，可能需要在測試系統中設置此值。