爲你的數據庫設計/性能專家在那裏。我正在設計一個表，我可以選擇使用int或nvarchar（128）作爲列，假設空間不是問題。我的問題是，這將給性能Sql Server int vs nvarchar性能比較？
當我爲int的列搜索
where ID = 12324
，或者當我與nvarchar列搜索（關鍵是整個價值，所以我沒有使用LIKE運算符）
where Key = 'my str'
我敢肯定，對於較小的數據集也無所謂，但是讓我們假設這個數據將在數百萬行的。
INT會更快 - 這裏的原因：
所以網頁約200項爲相同數量的索引條目，則NVARCHAR（ 128）ca se會使用十倍的索引頁面。
加載和搜索這些索引頁將會產生更多的I/O操作。
所以要簡短：如果可以的話，總是使用INT。
性能與此主要問題是字段的大小 - int是4個字節，而nvarchar(128)將是254個字節。
所有這些都需要由SQL服務器管理，因此管理int將比nvarchar(128)快得多。
空間是總是數據庫的問題。更寬的鍵意味着每頁更少的條目，更多的頁面掃描到聚合和總和值，意味着更多的IO，更少的性能。對於聚簇索引，此問題會與每個非聚簇索引相乘，因爲它們必須在其葉子中重新生成查找鍵（聚簇鍵）。所以nvarchar(128)類型的鑰匙將會差不多總比INT差。
另一方面，如果不合適，請不要使用INT鍵。考慮到您的查詢，請始終使用相應的密鑰。如果您總是要通過nvarchar（128）列值進行查詢，那麼可能是一個好的聚類關鍵人選。如果你打算聚合由nvarchar（128）鍵，那麼可能是一個很好的聚類關鍵人選。
+1：自然>人造鑰匙，但有很少的自然鑰匙IME。 – 2010-07-19 19:35:11
我會使用int來獲得性能（如果這將會特別加入連接）並且將唯一索引放置在數據完整性的潛在自然鍵上。
+1好點。另外，讓CPU處理一個int而不是一個字符串的工作要少一些。有了數百萬行，這可能會導致不可忽視的差異。我很想看到一些真正的性能測試。 – 2010-07-19 19:45:41