Varchar上的索引？

Question

我們在生產中遇到了一些繁重的表鎖問題。我注意到我創建了一個存儲過程，它通過訂單號獲取訂單列表。訂單號是一個VARCHAR（150）。本專欄沒有任何類型的索引。

目前，這個列中有很多NULL值。然而，隨着時間的推移（最近這張桌子上線了），這張桌子將會顯着增長。此時不會再添加NULL值。

我的問題是兩倍。首先，這裏的指數會有好處。該過程大量使用。如果是這樣，它應該聚集還是不聚集？數據就像CP123456，DR126512一樣。

可能影響第一個問題的第二個問題是 - 將列更改爲CHAR（10）會有好處，因爲它似乎是訂單號總是相同的大小。將索引放在固定長度的CHAR上，而不是VARCHAR（150）有什麼好處？

（大小不同是因爲創建列時的未知要求）。

SQL Server 2008的

Answer 1

1. 是的，絕對！繼續前進並添加索引。對索引進行聚簇在這裏可能是不必要的，如果在表上已經有了另一個聚簇索引（例如主鍵），那麼將不可能。

2. 將列更改爲CHAR(10)在存儲大小方面可能有一些好處，但它不太可能在索引性能方面產生特別大的差異。現在我會跳過它。

Answer 2

我沒有參考引用此，只有經驗/軼事證據。

首先，查詢可以幾乎總是可以通過使用指標的改善。確切的好處取決於查詢。
- 如果查詢只需要特定的記錄/表中的一小部分，索引將有助於
- 如果查詢需要全表，但可以從有序的數據中受益，索引將有助於

集羣索引通常提供比非集羣索引更高的性能優勢。在非常簡單的意義上，使用非聚集索引就像使用兩個表並將它們連接起來（首先使用搜索友好索引，然後將其連接到數據本身 - 除非索引包含所需的所有數據字段）。

然而，這裏的一個考慮因素是數據添加到表格的順序。如果您的聚集索引意味着數據經常在表格中間插入或刪除，您將會看到碎片和其他文物。但是，根據我的經驗，只有在極端情況下才需要對此進行認識和考慮。

總之，絕對指標數據。聚簇索引通常最適合用來處理性能最差的查詢。

至於VARCHAR和CHAR之間的區別？在過去的日子裏，將可變長度字段保留在數據末尾非常重要，以便使固定長度字段更容易識別。這意味着將VARCHAR字段作爲您的第一個字段，並將其用作唯一標識符，這相當糟糕。

現在，性能差異很小。就個人而言，我仍然保持固定長度的唯一標識符。可變長度數據通常不會有明顯的性能成本，但是當你實際上對連接謂詞等進行比較時，如果可能的話，定長字段會更加整齊。