我是否有理由不应该在 Sql Server 中使用 NVARCHAR？
我现在正在设计一个数据库方案，我认为为了安全起见，我应该使用 nvarchar 作为我的文本列的数据类型（用于 unicode 支持）。 虽然我不希望出现非英文文本，但我认为最好从一开始就支持它，以防万一。
我有什么理由应该坚持使用纯 varchar 吗？ 表现？
I'm designing a database scheme right now and I figure just to be safe I should use nvarchar for my textual column's datatypes (for unicode support). While I don't expect non-english text I figure it would be better to have support it from the begining just in case.
Is there any reason why I should stick with plain varchar? Performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在当今的 i18n 世界中，nvarchar 很有意义。 varchar 对于指定为非 unicode 的数据可能有意义（也许您有一些要求为 ASCII 的系统字段）。
默认情况下，我会使用 nvarchar 来表示名称、描述、地址等内容。
varchar较小，因此使用varchar可能比nvarchar 节省一些 IO（但请注意，代码页也成为一个更大的问题）。In today's i18n world, nvarchar makes a lot of sense. varchar might make sense for data that is specified not to be unicode (perhaps you have some system fields that are demanded to be ASCII).
I'd use nvarchar by default for things like names, descriptions, addresses, etc.
varcharis smaller, so there are perhaps some IO savings withvarcharovernvarchar(but note that code-page becomes a bigger issue too).另外，请参阅这个问题：VARCHAR vs NVARCHAR 性能。 就
我个人而言，我建议坚持使用 varchar （如我在这个帖子中回答过）。 这会带来不小的性能开销。
Also, see this question: VARCHAR vs NVARCHAR performance.
Personally, I say stick to varchar (as I answered in this thread). There is a non-trivial performance overhead.
我们几乎在所有情况下都使用 VARCHAR，而 NVARCHAR 只是非常非常偶尔地使用。
产品代码不需要 NVarchar - 我们不允许其中包含除 AZ、0-9 和“_”以外的任何内容...
它是存储空间的两倍，但每个索引页（和每个数据）也只有一半的条目页），一半的内存缓存被“浪费”，更多的 CPU 周期用于比较数据，等等。
IME 中常用的外国口音可以在 Varchar 中找到（即 LATIN-1）。 我们没有计划制作中文或其他替代字符集，当我们能够通过从第一天开始使用 NVarchar 来处理该字符集时，我们将不再担心 - 文本从右到左或垂直对齐？ :(
如果您允许使用 NVarchar，例如，一个名称，您将如何从键盘输入扩展字符？如果您导入数据（因此它已经是 NVarchar），您将如何搜索那个客户使用标准 QWERTY 键盘。很多很多都涉及到应用程序的国际化，所以我的观点是“允许使用 NVarchar”是没有意义的，
但是我又在很多地方使用了 NVarchar ...并且大多数栏目也有 50 个字符宽......他们一定知道一些关于人口增长和邮政编码扩展计划的信息，而我不知道！
We use VARCHAR for almost everything, and NVARCHAR only very very occasionally.
Product Codes don't need NVarchar - we don't allow anything other than A-Z, 0-9 and "_" in them ...
Its twice the storage space, but also only have half the entries per index page (and per data page) and half the memory cache is "wasted", more CPU cycles to compare data, and so on.
IME the commonly used foreign accents work just find in Varchar (i.e. LATIN-1). We have no plans to do Chinese or other alternate character sets, and when we do being able to handle that characterset by having using NVarchar from Day One will be the least of our worries - Right-to-Left or Vertical alignment of text?? :(
And if you allowed NVarchar for, say, a Name how are you going to type the extended charcater in from your keyboard? And if you import the data (so it is already NVarchar) how are you going to be able to search for that customer using your standard QWERTY keyboard. Lots and lots involved with internationalising an application, so my view is that there is no point "allowing for it by using NVarchar".
But there again lots of places I go to have NVarchar ... and most of the columns are 50 characters wide too .... they must know something about population growth and expansion plans for ZIP codes that I don't!!
是的，性能，尺寸。 nvarchar 需要更多字节，我认为它是双倍的（如果我错了请纠正我），这是因为 unicode 支持。 因此，如果您不需要 unicode 支持，请使用常规 varchar。
Yes, performance, in size. nvarchar takes more bytes, I think it's double (correct me if I'm wrong) and this is because of the unicode support. So if you don't need unicode support, go with regular varchar.
正如已经提到的，权衡是面向未来与性能。 根据我的经验，SQL Server 在 CPU 和内存限制较低的情况下表现得相当好，但如果磁盘 I/O 速度较慢，它就会出现问题。
如果您没有双字节字符集（即中文字符）的计划，请坚持使用 VARCHAR(MAX)。
As mentioned already, the trade off is future-proofing versus performance. In my experience, SQL Server does fairly well with lower CPU and memory limitations, but give it a slow disk I/O and it can really chug.
If you have no plans for dual-byte character sets (i.e. Chinese characters), stick with VARCHAR(MAX).
一般来说; 从约束最少的最昂贵的数据类型开始。 将其投入生产。 如果性能开始成为问题，请找出这些 nvarchar 列中实际存储的内容。 里面有没有不适合 varchar 的字符吗？ 如果不是，请切换到 varchar。 在知道痛点在哪里之前，不要尝试预先优化。 我的猜测是，在可预见的将来，nvarchar/varchar 之间的选择不会减慢您的应用程序的速度。 应用程序的其他部分的性能调整将为您带来更多收益。
Generally speaking; Start out with the most expensive datatype that has the least constraints. Put it in production. If performance starts to be an issue, find out what's actually being stored in those nvarchar columns. Is there any characters in there that wouldn't fit into varchar? If not, switch to varchar. Don't try to pre-optimize before you know where the pain is. My guess is that the choice between nvarchar/varchar is not what's going to slow down your application in the foreseable future. There will be other parts of the application where performance tuning will give you much more bang for the bucks.