sql server中，nchar(n)和nvarchar(n)；char(n)和varchar(n)两组数据类型的区别和使用
char(n1)，varchar(n1)，nchar(n2)，nvarchar(n2)
-
char就是指代character，缩写而已。
-
char和varchar采取单字节编码存储。sql server大概默认就是ASCII了，当然，这个应该是可以自定义的。单字节存储对汉字（包括简体汉字、繁体汉字、日文汉字等，或者说其他的超了范围的语言文字）来说明显就不够用了。
-
nchar和nvarchar采取多字节编码存储。单字节不够用，那就搞更多字节，不一定是两个字节，也可能用更多字节，具体看编码的方案。n是national的缩写，国际化，把大伙儿用的字符都兼容掉问题就解决了。
-
十分确信字段只存ASCII范围内字符的时候，那么就用char或者varchar，否则就老老实实用nchar或者nvarchar。
-
文档上说，varchar是char varying或character varying的缩写;nvarchar是national char varying或national character varying的缩写。
-
n1的单位是1个字节（byte-pairs），n2的单位是2个字节（byte），并不表示字段能存多少个字符。普通汉字之类用两个字节存就行，但是，对于超范围的补充字符（Supplementary Character，in higher Unicode ranges(65,536-1,114,111) ），一个字符需要四个字节存储。这点可能是和MySql区别最明显的地方了。
C#代码验证：在一个StringBuilder变量里存一个补充字符，确实占用了4个字节，但其Length属性也变成了“2”。VS的注释说Length是表示字符串中字符的个数，这句话就不对了，这里就出现了一个字符的Length属性是“2”的情况，可见，Length属性仅表示字符串实际占用的字节对（byte-pairs）数量而已。 -
string类型数据的大容量都是8000字节（byte）。而这里n1的范围是1-8000，n2的范围是1-4000。n1的单位量是1个字节，n2的单位量是2个字节。
-
varchar(max)和nvarchar(max)的最大容量是2GB（2^31-1 bytes，这比mysql要大的多），所以，只要定义为MAX这种，就不会出现字段长度不够用问题，如果有问题，那就是数据库设计本身有问题。另外，一般字段通常的最大存储容量都是2GB，包括各种可变长文本，图片，音频等文件之类。
-
SSMS里查到的表格显示的字符串数据的长度是有限制的，非XML数据，最大显示 65535 byte（2^16=65536），也就是64kb。但是实际查询能看的字符串长度（直接copy出来）的只有43680。通过LEN函数或者用代码查询可以看到字段的实际长度和实际内容。注意，这里对查询结果做copy或者save result as得到的是截断后的数据。
-
注意诸多的字符串函数的使用。
-
关于存储GUID时候用什么类型：char(32)可以存储，需要用到32个字节；uniqueidentifier可以存储，但是仅用16个字节即可，明显还是用专用的uniqueidentifier。GUID是32位的不差，但是通过从 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（32个字符） 形式的GUID字符串常量进行转换，其中，每个 x 都是 0-9 或 a-f 范围内的十六进制数字，因此只要16个字节就足够存储GUID数据了，一个字节是8bit，一个16进制只需要4bit，所以一个字节可以存两个16进制。
-
超长的字符串用varchar(max)或者nvarchar(max)，不用text，ntext之类，不要看名字觉得text，ntext是专门定义给长字符串用的，误解而已。
ref:https://docs.microsoft.com/en-us/sql/t-sql/data-types/nchar-and-nvarchar-transact-sql?view=sql-server-ver15
ref:https://docs.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql?view=sql-server-ver15
ref:https://docs.microsoft.com/en-us/cpp/c-runtime-library/single-byte-and-multibyte-character-sets?view=msvc-160
ref:https://dev.mysql.com/doc/refman/8.0/en/char.html
