在过去的几年里，我们所有的项目都使用了NVARCHAR，因为所有这些项目都是多语言的。从外部源导入的数据(例如ASCII文件等)在插入到数据库之前被上转换为Unicode。

我还没有遇到任何与较大索引相关的性能问题，等等。索引确实会使用更多的内存，但是内存很便宜。

无论您是使用存储过程还是动态构造SQL，都要确保所有字符串常量都有N前缀(例如SET @foo = N' hello world.';)，这样常量也是Unicode。这避免了在运行时进行任何字符串类型转换。

YMMV。

如果您使用NVARCHAR只是因为系统存储过程需要它，最常见的情况是莫名其妙的sp_executesql，并且您的动态SQL非常长，那么从性能角度来看，您最好在VARCHAR中进行所有字符串操作(连接、替换等)，然后将最终结果转换为NVARCHAR并将其输入到proc参数中。所以，不要总是使用NVARCHAR!

由于您的应用程序很小，使用nvarchar与使用varchar相比，基本上没有明显的成本增加，而且如果您需要存储unicode数据，您也省去了潜在的麻烦。

For your application, nvarchar is fine because the database size is small. Saying "always use nvarchar" is a vast oversimplification. If you're not required to store things like Kanji or other crazy characters, use VARCHAR, it'll use a lot less space. My predecessor at my current job designed something using NVARCHAR when it wasn't needed. We recently switched it to VARCHAR and saved 15 GB on just that table (it was highly written to). Furthermore, if you then have an index on that table and you want to include that column or make a composite index, you've just made your index file size larger.

做决定时要考虑周全;在SQL开发和数据定义中，似乎很少有“默认答案”(当然，除了不惜一切代价避免游标)。

是一致的!加入一个VARCHAR到NVARCHAR有一个很大的性能打击。

在某些特殊情况下，您会有意限制数据类型，以确保它不包含某个特定集合中的字符。例如，我有一个场景，我需要在数据库中存储域名。域名的国际化在当时是不可靠的，所以最好限制在基础水平上的输入，并有助于避免任何潜在的问题。