NChar或Char是否比它们的var替代品表现更好?

好问题。在某些情况下，简单的答案是肯定的。让我们看看这是否可以解释。

Obviously we all know that if I create a table with a column of varchar(255) (let's call this column myColumn) and insert a million rows but put only a few characters into myColumn for each row, the table will be much smaller (overall number of data pages needed by the storage engine) than if I had created myColumn as char(255). Anytime I do an operation (DML) on that table and request alot of rows, it will be faster when myColumn is varchar because I don't have to move around all those "extra" spaces at the end. Move, as in when SQL Server does internal sorts such as during a distinct or union operation, or if it chooses a merge during it's query plan, etc. Move could also mean the time it takes to get the data from the server to my local pc or to another computer or wherever it is going to be consumed.

但是使用varchar会有一些开销。SQL Server必须使用一个双字节指示器(开销)，在每一行上，知道特定行的myColumn中有多少字节。造成问题的不是额外的2个字节，而是必须“解码”myColumn中每一行的数据长度。

In my experiences it makes the most sense to use char instead of varchar on columns that will be joined to in queries. For example the primary key of a table, or some other column that will be indexed. CustomerNumber on a demographic table, or CodeID on a decode table, or perhaps OrderNumber on an order table. By using char, the query engine can more quickly perform the join because it can do straight pointer arithmetic (deterministically) rather than having to move it's pointers a variable amount of bytes as it reads the pages. I know I might have lost you on that last sentence. Joins in SQL Server are based around the idea of "predicates." A predicate is a condition. For example myColumn = 1, or OrderNumber < 500.

因此，如果SQL Server正在执行一个DML语句，而谓词或被连接的“键”是一个固定长度(char)，查询引擎不需要做大量的工作来匹配从一个表到另一个表的行。它不需要找出数据在行中有多长，然后沿着字符串找到结尾。所有这些都需要时间。

现在请记住，这很容易被糟糕地执行。我曾在在线系统中看到过用char作为主键字段。宽度必须保持较小，即char(15)或其他合理的值。它在在线系统中工作得最好，因为您通常只检索或上传少量行，因此必须“rtrim”结果集中的尾随空格，这是一项微不足道的任务，而不必将一个表中的数百万行连接到另一个表中的数百万行。

在在线系统上，CHAR比varchar更有意义的另一个原因是它减少了页面分割。通过使用char，你实际上是在“保留”(和浪费)这个空间，所以如果一个用户后来把更多的数据放到那个列中，SQL已经为它分配了空间。

使用CHAR的另一个原因与第二个原因类似。如果程序员或用户对数百万行进行“批处理”更新，例如在注释字段中添加一些句子，您不会在半夜接到DBA的电话，询问为什么他们的驱动器已满。换句话说，它导致数据库规模的增长更加可预测。

以上就是联机(OLTP)系统从char优于varchar中获益的3种方式。我很少在仓库/分析/OLAP场景中使用char，因为通常你有太多的数据，所有这些char列加起来会浪费大量的空间。

请记住，char会使您的数据库更大，但大多数备份工具都有数据压缩，因此您的备份往往与使用varchar时的大小相同。例如LiteSpeed或RedGate SQL Backup。

另一个用途是在为将数据导出到固定宽度文件而创建的视图中。假设我必须将一些数据导出到一个平面文件中以供主机读取。它是固定宽度(没有分隔)。我喜欢将数据以varchar的形式存储在“staging”表中(从而在数据库中消耗更少的空间)，然后使用一个视图将所有内容CAST为它的char等效值，其长度对应于该列的固定宽度的宽度。例如:

create table tblStagingTable (
pkID BIGINT (IDENTITY,1,1),
CustomerFirstName varchar(30),
CustomerLastName varchar(30),
CustomerCityStateZip varchar(100),
CustomerCurrentBalance money )

insert into tblStagingTable
(CustomerFirstName,CustomerLastName, CustomerCityStateZip) ('Joe','Blow','123 Main St Washington, MD 12345', 123.45)

create view vwStagingTable AS
SELECT CustomerFirstName = CAST(CustomerFirstName as CHAR(30)),
CustomerLastName = CAST(CustomerLastName as CHAR(30)),
CustomerCityStateZip = CAST(CustomerCityStateZip as CHAR(100)),
CustomerCurrentBalance = CAST(CAST(CustomerCurrentBalance as NUMERIC(9,2)) AS CHAR(10))

SELECT * from vwStagingTable

This is cool because internally my data takes up less space because it's using varchar. But when I use DTS or SSIS or even just a cut and paste from SSMS to Notepad, I can use the view and get the right number of trailing spaces. In DTS we used to have a feature called, damn I forget I think it was called "suggest columns" or something. In SSIS you can't do that anymore, you have to tediously define the flat file connection manager. But since you have your view setup, SSIS can know the width of each column and it can save alot of time when building your data flow tasks.

所以底线是……使用varchar。使用char的原因很少，而且仅仅是出于性能方面的考虑。如果您有一个有数亿行的系统，如果谓词是确定性的(char)，您将看到一个显著的差异，但对于大多数系统来说，使用char只是浪费空间。

希望这能有所帮助。 杰夫

这是典型的空间与性能的权衡。

在MS SQL 2005中，Varchar(或每个字符需要两个字节的语言，如中文)是可变长度的。如果您在将行写入硬盘后再添加数据，则会将数据定位在与原始行不相邻的位置，并导致数据文件碎片化。这将影响性能。

所以，如果空间不是问题，那么Char格式的性能更好，但如果你想保持数据库的大小，那么varchars格式更好。

我支持吉姆·麦基思的评论。

此外，如果您的表只有CHAR列，那么索引和全表扫描会更快。基本上，优化器将能够预测每条记录有多大，如果它只有CHAR列，而它需要检查每个VARCHAR列的大小值。

此外，如果您将VARCHAR列更新到比其先前内容更大的大小，则可能会强制数据库重新构建其索引(因为您强制数据库将记录物理地移动到磁盘上)。而对于CHAR列，这种情况永远不会发生。

但是，除非表很大，否则您可能不会关心性能受到的影响。

记住吉布拉的至理名言。早期的性能优化是万恶之源。

一般规则是，如果所有行的长度接近相同，则选择CHAR。当长度变化显著时，选择VARCHAR(或NVARCHAR)。CHAR也可能更快一些，因为所有的行都是相同的长度。

它因数据库实现而异，但通常，VARCHAR(或NVARCHAR)除了实际数据之外，还会使用一到两个字节的存储空间(用于长度或终止)。因此(假设您使用的是单字节字符集)存储单词“FooBar”

CHAR(6) = 6字节(无开销) VARCHAR(100) = 8字节(2字节开销) CHAR(10) = 10字节(4字节浪费)

最重要的是，对于相对相同长度的数据(在两个字符长度差以内)，CHAR可以更快、更节省空间。

注意:Microsoft SQL对于一个VARCHAR有2个字节的开销。这可能因DB而异，但通常至少需要1个字节的开销来指示VARCHAR上的长度或EOL。

正如Gaven在评论中指出的:当涉及到多字节字符集时，情况会发生变化，在这种情况下VARCHAR会成为更好的选择。

关于VARCHAR声明长度的注意事项:因为它存储了实际内容的长度，所以您不会浪费未使用的长度。因此，在VARCHAR(6)、VARCHAR(100)或VARCHAR(MAX)中存储6个字符使用相同的存储量。阅读更多关于使用VARCHAR(MAX)时的差异。在VARCHAR中声明最大大小以限制存储的容量。

在评论中AlwaysLearning指出Microsoft Transact-SQL文档似乎说的恰恰相反。我认为这是一个错误，或者至少文件不清楚。

我认为在你的情况下，可能没有理由不选择Varchar。它为您提供了灵活性，正如许多受访者所提到的，现在的性能是这样的，除非在非常特定的情况下，我们普通人(而不是谷歌DBA)不会注意到差异。

当谈到DB类型时，值得注意的一件有趣的事情是sqlite(一个非常受欢迎的迷你数据库，具有相当令人印象深刻的性能)将所有内容作为字符串放入数据库并动态地输入类型。

我总是使用VarChar，通常使它比我可能迫切需要的要大得多。如你所说，为了安全起见，为什么不买50英镑呢?

Char更快一点，所以如果你知道一个列有一定的长度，就使用Char。例如，存储(M)ale/(F)emale/(U)nknown表示性别，或者存储2个字符表示美国的一个州。