是否值得將PRIMARY KEY從NVARCHAR類型切換到INT類型？

在我們的SQL SERVER 2008 R2數據庫中，我們有一個COUNTRIES包含國家的參考表。該PRIMARY KEY是一個nvarchar列：是否值得將PRIMARY KEY從NVARCHAR類型切換到INT類型？

create table COUNTRIES(
    COUNTRY_ID nvarchar(50) PRIMARY KEY, 
    ... other columns 
)

主鍵包含了諸如「FR」，「GER」，「美國」，「英國」等，這表包含最大值。 20排。

我們也有一個SALES表包含銷售數據：

create table SALES(
    ID int PRIMARY KEY 
    COUNTRY_ID nvarchar(50), 
    PRODUCT_ID int, 
    DATE datetime, 
    UNITS decimal(18,2)   
    ... other columns 
)

這種銷售表包含還nvarchar類型的命名COUNTRY_ID列（而不是主鍵）。這個表格要大得多，大約有2000萬行。

在我們的應用程序中，當查詢SALES表格時，我們幾乎每次都在COUNTRY_ID上進行過濾。即使如此，執行大多數聚合查詢也需要很長時間（即使使用適當的索引）

我們正處於開發階段，以提高SALES表上的查詢性能。我的問題是：

是否值得將COUNTRY_ID類型從nvarchar(50)改爲int類型？如果COUNTRY_ID列在兩個表中都轉換爲int類型，那麼在連接兩個表時能否獲得更好的性能？

來源

2013-07-04 Lucian

這是一個潛在的[複製]（http://stackoverflow.com/questions/332300/is-there-減少一個實時的性能差之間-INT和 - VARCHAR-主密鑰）。 – Scott

@Scott - 事件如果這幾乎是一樣的話，那個問題就是指MySQL，而不是SQL Server。在那裏的一些答案可以匹配我的情況，但我希望得到一些更具體的SQL Server技術答案（也許一些數字也）。我希望你們不會關閉我的問題 – Lucian

當你有連接時，int可能會更快，但另一方面，擁有語義主鍵可能意味着你甚至不需要加入國家/地區表，因爲你可以直接在外鍵上過濾。 – alun

我個人建議將COUNTRY_ID從nvarchar(50)更改爲INT。一個int使用4字節的數據，通常比VARCHAR更快至JOIN。

您還可以查看是否使用的空間是通過使用stored procedure sp_spaceused

EXEC sp_spaceused 'TableName'

來源

2013-07-04 12:00:52

感謝您使用'sp_spaceused'。我做了一些測試，在數據使用的空間上我只獲得了101Mb（1855488 KB和1751408 KB）。這些指標所佔用的空間幾乎相同（差異爲91 Mb）。我想從這個角度來看沒有太大的區別。 – Lucian

@Lucian - 這仍然是一個很好的空間來保存。隨着桌子的增長，節省的空間將變得有價值。 –

是否值得將PRIMARY KEY從NVARCHAR類型切換到INT類型？

回答

相關問題