ms sql数据库里char、varchar、text和nchar、nvarchar、ntext的区别
转自：梦仙士 http://blog.sina.com.cn/s/blog_724cf46101011hvi.html
char、varchar、text和nchar、nvarchar、ntext的区别
varchar在SQL Server中是采用单字节来存储数据的，nvarchar是使用Unicode来存储数据的．中文字符存储到SQL
Server中会保存为两个字节（一般采用Unico编码），英文字符保存到数据库中，如果字段的类型为varchar，则只会占用一个字节，而如果字段的类型为nvarchar，则会占用两个字节．
正常情况下，我们使用varchar也可以存储中文字符，但是如果遇到操作系统是英文操作系统并且对中文字体的支持不全面时, 在SQL
Server存储中文字符为varchar就会出现乱码(显示为??)．而且正常情况下，主机都会支持中文的环境，所以如果使用varchar来存储数据，在开发阶段是发现不了的．多数情况下，在布署的时候也不会有问题．
但是！如果布署的主机是英文操作系统，并且不支持中文环境，那问题就出来了．所有的varchar字段在存储中文的时候都会变成乱码（显示为??）．而且一般情况下你不会知道这是因为你采用了错误的数据类型来存储所造成的，你会试着去装中文字体，试着去设置操作系统的语言环境．．．这些都不能解决问题，唯一能解决问题的是把数据库字段的类型个性为nvarchar（或者nchar）．对项目管理比较熟悉的朋友应该都知道，到布署阶段再来修改数据库是一个很恐怖的事情．
使用nvarchar的另一个非常好处就是在判断字符串的时候可以不需要考虑中英文两种字符的差别．
当然，使用nvarchar存储英文字符会增大一倍的存储空间．但是在存储代价已经很低廉的情况下，优先考虑兼容性会给你带来更多好处的．
所以在Design的时候应该尽量使用nvarchar来存储数据．只有在你确保该字段不会保存中文的时候，才采用varchar来存储．------------------------------
1、 varchar： 可变长度的非
Unicode
数据，最长为
8,000
个字符。
2、nvarchar：
可变长度 Unicode
数据，其最大长度为
4,000
字符。
3、char:
固定长度的非 Unicode
字符数据，最大长度为
8,000
个字符。
4、nchar
固定长度的
Unicode
数据，最大长度为
4,000
个字符。
5、
char和varchar都是字符串类型的 用Unicode编码的字符串,结果是字符的整数值.
有时中文也可以考虑VARCHAR，毕竟有时候在前台语言处理字符长度好一些，权衡来看，unicode自己抉择，推荐使用NVARCHAR。=======================================================如果
varchar(300)
和 varchar(8000)
都存储相同的字符数，性能上是没有差别的，存储行为上也没有不同。因为它们都有相同的存储结构，两个字节的偏移，两个字节的列数（如果表中所有的列都是 varchar
类型）。区别只在于存储容量上。 大多数的性能比较都集中在
varchar
和
char，varchar
和
varchar(max)
上。还有，行外存储（SQL Server 2005
支持的）。 varchar(max)
（）与 varchar
存储方式是不同的。 当 LOB 数据足够小时，可以考虑将数据直接存储在数据行（行所在的数据页面）中，从而可以避免额外的读取 LOB
页面，提升访问 LOB 数据的效率（将 LOB 数据直接存储在数据页面的阈值由 text
in
row 选项设置）。 而当 LOB 数据大于此阈值，或者所在行的大小超过了
8060
字节（单行最大 SIZE），LOB 数据将会存储在 LOB 页面，而在数据页面中保留一个指向 LOB 页面的
16
字节的指针。其访问效率当然会将低。 另外还有，恶意用户可以利用这一点“撑爆”你的磁盘。
======================
text最好不用,只适于存储大数据,还要用专门的函数来读写更新,麻烦
1.text能不用就不用
2.ntext
等，不需要就不用
3.char比varchar效率高一些(请高人判断一下这句是否正确)
4.text呢？效率比别两种慢不慢？除了存地数据多之外，还有没有别的优势？
文本型数据中你可以存储超过20亿个字符串，怎么样，这个够大了吧？但是也不是任何时候都是和使用文本型数据，因为他非常占空间，也非常消耗服务器，随处乱用后果不堪设想！因为即使你像一个文本型字段输入了一个空值他都会占用2K的空间！而当这时除了删除该数据没有别的办法收回空间！效率不高这个可以肯定
不能比较或排序 text、ntext
和
image
数据类型 最近在开发一个文件管理系统的时候，遇到一个问题：本来偶在本地的数据库是SQL2008，有一个字段SharedUserId
是nvarchar(max)类型，偶在查询SQL语句中用了...AND
SharedUserId
<>
''，
可以正常执行。后来把程序发布到买的空间服务器上，服务器上是SQL2000的数据库，因为SQL2000没有nvarchar(max)类型，所以偶改成了text类型，结果在执行同样的SQL语句时程序就报错了:
MySQL和MSSQL下，text
、ntext、
image、blob的比较
sm_crystal /
2011-09-28
/
字体大小选择：
1、MySQL存在text和blob：
(1)、相同
在TEXT或BLOB列的存储或检索过程中，不存在大小写转换,当未运行在严格模式时，如果你为BLOB或TEXT列分配一个超过该列类型的最大长度的值值，值被截取以保证适合。如果截掉的字符不是空格，将会产生一条警告。使用严格SQL模式，会产生错误，并且值将被拒绝而不是截取并给出警告。
BLOB和TEXT列不能有默认值。
当保存或检索BLOB和TEXT列的值时不删除尾部空格。(这与VARBINARY和VARCHAR列相同）。
对于BLOB和TEXT列的索引，必须指定索引前缀的长度。对于CHAR和VARCHAR，前缀长度是可选的。
(2)、相异
text
: TEXT值是大小写不敏感的 Text被视为非二进制字符串 TEXT列有一个字符集，并且根据字符集的 校对规则对值进行排序和比较
可以将TEXT列视为VARCHAR列 MySQL连接程序/ODBC将TEXT值定义为LONGVARCHAR
BLOB
可以储存图片,TEXT不行，TEXT只能储存纯文本文件。4个TEXT类型TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT对应于4个BLOB类型，并且有同样的最大长度和存储需求。
blob: BLOB值的排序和比较以大小写敏感方式执行; BLOB被视为二进制字符串;
BLOB列没有字符集，并且排序和比较基于列值字节的数值值。 在大多数方面，可以将BLOB列视为能够足够大的VARBINARY列
MySQL连接程序/ODBC将BLOB值定义为LONGVARBINARY
一个BLOB是一个能保存可变数量的数据的二进制的大对象。4个BLOB类型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB仅仅在他们能保存值的最大长度方面有所不同。
(3)其他：
VARCHAR，BLOB和TEXT类型是变长类型，对于其存储需求取决于列值的实际长度(在前面的表格中用L表示)，而不是取决于类型的最大可能尺寸。例如，一个VARCHAR(10)列能保存最大长度为10个字符的一个字符串，实际的存储需要是字符串的长度
，加上1个字节以记录字符串的长度。对于字符串'abcd'，L是4而存储要求是5个字节。
BLOB和TEXT类型需要1，2，3或4个字节来记录列值的长度，这取决于类型的最大可能长度。VARCHAR需要定义大小，有255的最大限制；TEXT则不需要。如果你把一个超过列类型最大长度的值赋给一个BLOB或TEXT列，值被截断以适合它。
CHAR(n)
固定长度，最多 255
个字符
VARCHAR(n)
可变长度，MySQL 4.1
及以前最大
255
字符，MySQL
5
之后最大
65535
字节 TINYTEXT 可变长度，最多
255
个字符
TEXT
可变长度，最多
65535
个字符 MEDIUMTEXT 可变长度，最多
16777215（2^24
-
1）个字符
LONGTEXT 可变长度，最多 4294967295（2^32
-
1）（4G）个字符
2、MSSQL存在text、ntext和image：
ntext：
可变长度 Unicode
数据的最大长度为
2^30
-
1
(1,073,741,823)
个字符。存储大小是所输入字符个数的两倍（以字节为单位）。ntext
在 SQL-92
中的同义词是
national
text。
text：
服务器代码页中的可变长度非 Unicode
数据的最大长度为
2^31-1
(2,147,483,647)
个字符。当服务器代码页使用双字节字符时，存储量仍是 2,147,483,647
字节。存储大小可能小于
2,147,483,647
字节（取决于字符串）。
image：
在 Image
数据类型中存储的数据是以位字符串存储的，不是由 SQL Server 解释的，必须由应用程序来解释。例如，应用程序可以使用
BMP、TIEF、GIF 和 JPEG 格式把数据存储在 Image
数据类型中。
