是否值得将 PRIMARY KEY 从 NVARCHAR 类型切换到 INT 类型？答案

【问题标题】：does it worth switching a PRIMARY KEY from the type NVARCHAR to the type INT?是否值得将 PRIMARY KEY 从 NVARCHAR 类型切换到 INT 类型？
【发布时间】：2013-07-02 10:09:21
【问题描述】：

在我们的 SQL SERVER 2008 R2 数据库中，我们有一个包含国家/地区的 COUNTRIES 引用表。 PRIMARY KEY 是一个 nvarchar 列：

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

主键包含“FR”、“GER”、“US”、“UK”等值。此表包含最大值。 20 行。

我们还有一个包含销售数据的SALES 表：

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

此销售表包含一个名为COUNTRY_ID 的列，其类型也是nvarchar（不是主键）。这个表要大得多，包含大约 2000 万行。

在我们的应用程序中，当查询SALES 表时，我们几乎每次都在COUNTRY_ID 上进行过滤。即使这样，执行大多数聚合查询也需要很长时间（即使有适当的索引）

我们正处于改进SALES 表的查询性能的开发阶段。我的问题是：

是否值得将COUNTRY_ID 类型从nvarchar(50) 转换为int 类型？ 如果两个表中的列COUNTRY_ID 都转换为int 类型，我可以加入这两个表时期望更好的性能？

【问题讨论】：

这是一个潜在的duplicate。
@Scott - 如果情况几乎相同，那么该问题是指 MySQL，而不是 SQL Server。那里的一些答案可能与我的情况相匹配，但我希望获得更多特定于 SQL Server 的技术答案（也许还有一些数字）。我希望你们不要关闭我的问题
当你有连接时，int 可能会更快，但另一方面，拥有语义主键可能意味着你通常甚至不必加入国家表，因为你可以直接过滤外键。
@alun - 谢谢，我明白你的意思了。就我而言，我想在查询大表之前先在临时表中获取 INT 值。然后我可以使用这个临时表加入 SALES

标签： sql sql-server tsql primary-key query-performance

【解决方案1】：

我个人建议将 COUNTRY_ID 从 nvarchar(50) 更改为 INT。一个 int 使用 4 字节的数据，通常比 JOIN 更快。

您也可以使用stored procedure sp_spaceused查看使用的空间是否减少

EXEC sp_spaceused 'TableName'

【讨论】：

感谢sp_spaceused。我做了一些测试，我只获得了 101Mb 的数据使用空间（1855488 KB 与 1751408 KB）。索引占用的空间几乎相同（相差 91 Mb）。我想从这个角度来看没有太大区别。
@Lucian - 这仍然需要节省大量空间。随着表格的增长，节省的空间将变得有价值。