SQl服務器表：堆或不堆？

Question

我最近已經注意到我們有許多表存儲在堆中（沒有聚集索引）。你會選擇性地在它們上面創建聚集索引嗎？或者根本不創建聚集索引？其他任何智慧或建議？

有與25點左右的行一些「代碼」的表。但是，有好幾百萬行。

編輯 「大表」，他們都已經有索引，只是沒有聚集的指標。一些是日誌表，他們只是插入，幾乎沒有讀數。有一些相當重要的東西，大多隻是插入到應用程序中，然後閱讀一堆。

編輯 有PK的所有表，與一些我感興趣的，他們主要是剛插入一個時間，但看了很多次，以顯示屏幕。

在一些他們被插入在一個塊或一次相關行，並沒有更新或組多次讀取這些表中被完全刪除，然後重新插入再次作爲一個塊。它們通常在某個塊中讀取以顯示或進行計算。

在另一這些表的「類型」，行相關的行組被重複地插入，不同的基團插入所有的時間。在屏幕顯示中，需要返回完整的組。例如，隨着時間的推移這些基團的行被插入（其中的基團可以是5-50行）：

1:00pm A1, B1, C1, 
1:30pm A2, B2, C2, 
2:00pm A3, B3, C3, D1 
2:30pm A4,  C4, D2 
3:00pm   C5, D3, E1 
3:30pm    D4, E2 

屏幕將需要顯示完整集合A的：A1 + A2 + A3 + A4

編輯 基於@gbn答案提約碎裂，我用這個query from marc_s，發現與百萬+行堆表下面的碎片信息和被讀取很多次，使用屏幕：

TableName index_type alloc_unit_type index_depth index_level avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count avg_page_space_used_in_percent record_count ghost_record_count Version_ghost_record_count min_record_size_in_bytes max_record_size_in_bytes avg_record_size_in_bytes forwarded_record_count 
--------- ---------- --------------- ----------- ----------- ---------------------------- -------------- -------------------------- ---------- ------------------------------ ------------ ------------------ -------------------------- ------------------------ ------------------------ ------------------------ ---------------------- 
TABLE_A HEAP  IN_ROW_DATA  1   0   95.8294717330862    2069   8.18511358144031   16935  98.2659995058068    1125786  3     0       80      164      117.671     0 
TABLE_A HEAP  IN_ROW_DATA  1   0   95.8294717330862    2069   8.18511358144031   16935  98.2659995058068    1125786  3     0       80      164      117.671     0 
TABLE_A HEAP  IN_ROW_DATA  1   0   95.8314034275127    2070   8.18212560386473   16937  98.2559303187546    1125793  11     0       80      164      117.672     0 
TABLE_B HEAP  IN_ROW_DATA  1   0   99.2541594951233    1734   6.44982698961938   11184  94.5866567828021    1222729  0     0       68      82      68.037     0 
TABLE_B HEAP  IN_ROW_DATA  1   0   99.2541594951233    1734   6.44982698961938   11184  94.5866567828021    1222729  0     0       68      82      68.037     0 
TABLE_B HEAP  IN_ROW_DATA  1   0   99.197247706422    1735   6.44726224783862   11186  94.5725228564369    1222745  23     0       68      82      68.038     0 
TABLE_C HEAP  IN_ROW_DATA  1   0   71.5785224061365    1777   10.9527293190771   19463  97.4122807017544    2237831  0     0       9      84      66.588     2485 
TABLE_C HEAP  IN_ROW_DATA  1   0   71.5785224061365    1777   10.9527293190771   19463  97.4122807017544    2237831  0     0       9      84      66.588     2485 
TABLE_C HEAP  IN_ROW_DATA  1   0   71.589991928975    1778   10.9476940382452   19465  97.4023844823326    2237832  0     0       9      84      66.588     2485 
TABLE_D HEAP  IN_ROW_DATA  1   0   40.0769404842725    1773   19.7535250987028   35023  98.0193106004448    2778169  0     0       98      112      98.041     0 
TABLE_D HEAP  IN_ROW_DATA  1   0   40.0904977375566    1774   19.7480270574972   35033  98.0175315048184    2778821  0     0       98      112      98.044     0 
TABLE_D HEAP  IN_ROW_DATA  1   0   40.1040488577245    1775   19.7385915492958   35036  98.0142451198419    2778948  0     0       98      112      98.045     0 
TABLE_E HEAP  IN_ROW_DATA  1   0   97.1619365609349    2911   8.11473720371007   23622  99.390066716086    3333693  0     0       55      69      55.017     0 
TABLE_E HEAP  IN_ROW_DATA  1   0   97.1628838451268    2912   8.11332417582418   23626  99.3852359772671    3334016  0     0       55      69      55.018     0 
TABLE_E HEAP  IN_ROW_DATA  1   0   97.1638304971638    2913   8.11122554067971   23628  99.3799357548802    3334100  0     0       55      69      55.018     0 
TABLE_F HEAP  IN_ROW_DATA  1   0   21.9911471599199    8903   36.3093339323823   323262  94.6116753150482    4734053  44     0       521      535      521.046     0 
TABLE_F HEAP  IN_ROW_DATA  1   0   21.9911471599199    8903   36.3093339323823   323262  94.6116876698789    4734053  50     0       521      535      521.046     0 
TABLE_F HEAP  IN_ROW_DATA  1   0   21.9930761622156    8904   36.3057053009883   323266  94.6112428959723    4734079  78     0       521      535      521.047     0 
TABLE_G HEAP  IN_ROW_DATA  1   0   66.1932151660993    5649   11.9943352805806   67756  96.7873733629849    6632610  0     0       78      92      78.047     0 
TABLE_G HEAP  IN_ROW_DATA  1   0   66.1932151660993    5649   11.9943352805806   67756  96.7873733629849    6632610  0     0       78      92      78.047     0 
TABLE_G HEAP  IN_ROW_DATA  1   0   66.1971830985916    5650   11.9925663716814   67758  96.7855572028663    6632648  11     0       78      92      78.048     0 
TABLE_H HEAP  IN_ROW_DATA  1   0   11.5377268385864    5585   67.4340196956132   376619  92.3860637509266    6897347  0     0       9      427      406.418     3 
TABLE_H HEAP  IN_ROW_DATA  1   0   11.5449915110357    5576   67.5530846484935   376676  92.3849023968372    6898289  0     0       9      427      406.419     3 
TABLE_H HEAP  IN_ROW_DATA  1   0   11.5487458087518    5578   67.5313732520617   376690  92.3848035581913    6898534  0     0       9      427      406.42     3 
TABLE_I HEAP  IN_ROW_DATA  1   0   96.7330677290837    9715   8.232.3321225599209    3152049  0     0       76      534      195.879     0 
TABLE_I HEAP  IN_ROW_DATA  1   0   96.7333930883378    9716   8.23157678056814   79978  96.3298122065728    3152142  0     0       76      534      195.879     0 
TABLE_I HEAP  IN_ROW_DATA  1   0   96.7337183827923    9717   8.23114129875476   79982  96.3323696565357    3152420  0     0       76      534      195.876     0 
TABLE_J HEAP  LOB_DATA  1   0   0       NULL   NULL      87553  95.5205090190264    7790594  0     0       84      98      84.91     NULL 
TABLE_J HEAP  IN_ROW_DATA  1   0   31.2985438510012    23539   25.4966651089681   600166  96.4532863849765    7807684  0     0       435      1213      598.261     0 
TABLE_J HEAP  IN_ROW_DATA  1   0   31.2994591137993    23540   25.4959218351742   600174  96.4530145787003    7807780  0     0       435      1213      598.26     0 
TABLE_J HEAP  IN_ROW_DATA  1   0   31.3022047558782    23543   25.4936074417024   600196  96.4526068692859    7808096  0     0       435      1213      598.255     0 

我不確定爲什麼每個表格有多行，但avg_fragmentation_in_percent值幾乎看起來都相當高。閱讀時，這種碎片會成爲性能問題嗎？建議聚集索引對它們進行碎片整理？

Answer 1

始終添加聚簇索引。如果沒有聚集索引，則無法快速壓縮或整理表格。沒有它，你不能。

簡單化，但我敢打賭，一些性能問題可能會追溯到組織嚴重的數據。

Answer 2

我會考慮把一個聚集索引的大型表。 聚集索引定義記錄如何存儲的物理順序。這樣做的結果是可以更高效地存儲表中的行，並減少碎片。 我敢肯定，表格中至少會有一列可能成爲聚集索引的候選人。 （如果沒有，你可以創建一個新的列，其中包含創建記錄的日期和時間，並且你在該列上放置了一個聚集索引，我認爲這還是更好，根本沒有CI）。

編輯：如果大表確實是日誌表，不經常讀，然後他們可以保留爲堆。

Answer 3

這取決於表是如何使用的。通常情況下，我想要一個包含數百萬條記錄的表上的聚簇索引，但是您還需要考慮如何使用該表。添加索引會減慢插入速度，因爲它必須爲每個新記錄查找適當的頁面（並可能插入一個新頁面），而不是隻追加它。如果這些標題主要是數據的「轉儲」並且很少被檢查（例如緊急日誌記錄），那麼讓它們獨立可能會更好。

與往常一樣，您應該使用配置文件來找出最適合您的應用或系統的配置。

Answer 4

聲音就像數據庫是由知道自己在做什麼的人創建的。日誌表和小型代碼表恰恰是堆的意義。

如果目前數據庫沒有問題，我會保持原樣！

Answer 5

對於大型表格羣集索引總是一個好主意。即使只插入表格。 當然你的聚類密鑰應該是一個不斷增加的價值。

Answer 6

大型表上的聚集索引的一個問題是，存儲索引所需的緩衝存儲器（RAM）等於表的大小。沒有單獨的索引。非聚集索引僅存儲索引的數據，然後存儲表的主鍵或refid。所以一個正常的索引可能更適合RAM。如果您使用聚集索引進行搜索，並且表格很大，那麼您可能會輕易放慢速度。如果您的聚集索引是日期的一部分，並且您的搜索全部用於最近的日期，那麼聚集索引可能不會影響搜索性能，因爲您從不訪問全部內容。

我不同意宣稱聚集索引將減少數據碎片的海報。它增加了數據碎片。在普通表上，只有刪除會導致碎片。在將行添加到聚簇表中或更改聚簇索引的字段時，SQL必須對錶進行物理重新排序。這意味着打破和添加增加碎片的數據頁面。這就是爲什麼大家建議小心選擇一個聚類的領域，a）如果有的話不經常改變，並且b）總是增加。

我發現，當您的查詢需要經常返回多個「相關」行時，聚集索引在大型表上很有用。您可以使用集羣，以便相關的行連續存儲並更容易進行SQL檢索。我不一定聚集一張大桌子，以便我有一個新的搜索索引。

羣集確實具有的一個優點就像覆蓋索引一樣，是索引包含查詢嘗試返回的數據。從索引到表格沒有額外的步驟來獲取數據。

最後，你必須得到分析器，並運行一些測試。

我是否正確或錯過了某些東西？