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

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

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

使用CHAR (NCHAR)和VARCHAR (NVARCHAR)会在数据库服务器存储数据的方式上带来不同。第一个引入了尾随空格;我在SQL SERVER函数中使用LIKE操作符时遇到了问题。因此，我必须始终使用VARCHAR (NVARCHAR)来确保它的安全性。

例如，如果我们有一个表TEST(ID INT, Status CHAR(1))，你写一个函数列出所有具有特定值的记录，如下所示:

CREATE FUNCTION List(@Status AS CHAR(1) = '')
RETURNS TABLE
AS
RETURN
SELECT * FROM TEST
WHERE Status LIKE '%' + @Status '%'

在这个函数中，我们期望当我们输入默认参数时，函数会返回所有的行，但实际上并没有。将@Status数据类型更改为VARCHAR将解决该问题。

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

早期性能优化和使用最佳实践类型的规则之间存在差异。如果创建的新表中总是有固定长度的字段，那么使用CHAR是有意义的，在这种情况下应该使用它。这不是早期优化，而是实现经验法则(或最佳实践)。

即-如果你有一个2字母的状态字段，使用CHAR(2)。如果您有一个包含实际州名的字段，请使用VARCHAR。

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只是浪费空间。

希望这能有所帮助。 杰夫

There are performance benefits, but here is one that has not been mentioned: row migration. With char, you reserve the entire space in advance.So let's says you have a char(1000), and you store 10 characters, you will use up all 1000 charaters of space. In a varchar2(1000), you will only use 10 characters. The problem comes when you modify the data. Let's say you update the column to now contain 900 characters. It is possible that the space to expand the varchar is not available in the current block. In that case, the DB engine must migrate the row to another block, and make a pointer in the original block to the new row in the new block. To read this data, the DB engine will now have to read 2 blocks. No one can equivocally say that varchar or char are better. There is a space for time tradeoff, and consideration of whether the data will be updated, especially if there is a good chance that it will grow.