是否值得将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类型？

回答

相关问题