非數字索引的性能

Question

如果我在SQL Server數據庫上使用nvarchar（n）列作爲聚簇索引，那麼與數字（int）索引相比，我會遭受顯着的性能下降嗎？另外複合指標的表現如何比較？

Answer 1

Sql並不在意你的索引是否是數字，但有些事情需要考慮，具體取決於列中的內容以及你如何使用表格。

一般來說，你要保持你的指標儘可能的小，從而爲nvarchar（4000）（8000個高達字節）那真是糟透了。但一個varchar（3）（3個高達字節）會比INT（4個字節）的情況。你也想（在可能的情況下）將你的索引插入插入到索引的末尾，這樣會導致索引分裂並導致性能問題。

如果您針對該表運行的查詢僅包含索引中的列，則化合物索引可以大大提高性能。這意味着當索引滿足查詢時，實際表格甚至不會被觸及。

有關索引的概述，請參閱Sql server index basics。

如果您提供關於表本身的更多具體細節以及如何使用它，可能會更有幫助？

Answer 2

幾乎可以肯定是的。

狹窄，數字和嚴格單調是一個很好的聚集鍵。 nvarchar不是這些。

每個非聚集索引條目引用聚集索引，因此您也會膨脹NC索引。

這是整理/比較問題之前。

Answer 3

我認爲這也取決於你的表的大小。對於較小的表格，我懷疑你會注意到一個區別，但對於較大的表格，說100萬行甚至更多，你可能會看到nvarchar的輕微放緩。我會說這也依賴於什麼領域實際contains..i.e，是他們的電子郵件等

Answer 4

科林，

爲nvarchar使用VARCHAR列兩倍的空間。如果nvarchar列是表上唯一的索引，那麼命中可能不那麼多，但如果在該表上還有非聚簇索引，那麼是的，你將會有性能問題。這是因爲聚簇索引也包含在非聚簇索引的所有行中，並且非聚簇索引將非常寬。另一方面，int列只佔用4個字節，並具有很大的範圍以存儲從-2,147,483,648到2,147,483,647的值，並且往往是窄的。對於4個字節，nvarchar列最多隻能存儲varchar（2）使用的空間，因爲它使用varchar列的空間的兩倍。你看到你有多少空間浪費？

Answer 5

在談論索引時，必須將「性能」分爲兩個主題。比非集羣聚集索引更是這樣，因爲它可能要在底層數據存儲遷移數據 -

在插入，更新和刪除，該指數將減緩你的數據庫了。在這裏，我同意John的說法，順序int將比nvarchar更好。

但是，如果你需要反正在爲nvarchar現場查詢，在該領域的聚簇索引將更加加快你的閱讀。

所以你的問題的答案真的取決於你是否擔心插入或讀取性能。