SQL中char、varchar、nchar、nvarchar 详解

char
    char是定长的,也就是当你输入的字符小于你指定的数目时,char(8),你输入的字符小于8时,它会再后面补空值。当你输入的字符大于指定的数时,它会截取超出的字符。

 

varchar[(n)]  
    长度为n 个字节可变长度且非 Unicode 的字符数据。n必须是一个介于1 和8,000 之间的数值。存储大小为输入数据的字节的实际长度,而不是n 个字节。所输入的数据字符长度可以为零。

nchar

固定长度,存储Unicode字符,不足的补英文半角空格

 
nvarchar(n)
    包含n 个字符可变长度 Unicode 字符数据。n的值必须介于1 与4,000 之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。 

 

1、CHAR。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间。 

 2、VARCHAR。存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。  
从空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点

3、TEXT。text存储可变长度的非Unicode数据,最大长度为2^31-1(2,147,483,647)个字符。 

4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符

我们知道字符中,英文字符只需要一个字节存储就足够了,但汉字众多,需要两个字节存储,英文与汉字同时存在时容易造成混乱,Unicode字符集就是为了解决字符集这种不兼容的问题而产生的,它所有的字符都用两个字节表示,即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来,nchar、nvarchar则最多存储4000个字符,不论是英文还是汉字;而char、varchar最多能存储8000个英文,4000个汉字。


可以看出使用ncharnvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。 

因此:

如果含有中文字符,用nchar/nvarchar;

如果纯英文和数字,用char/varchar。

 

另(1)定义:

char:   固定长度,存储ANSI字符,不足的补英文半角空格。

nchar:  固定长度,存储Unicode字符,不足的补英文半角空格

varchar: 可变长度,存储ANSI字符,根据数据长度自动变化。

nvarchar:可变长度,存储Unicode字符,根据数据长度自动变化。

注意:ANSI主要是以单字节来存储数据,一般适合英文。而我们常用的汉字需要用两个字节来存储,所以就要使用unicode的数据类型,不然读取出来的数据可能会乱码。

(2)区别:

     ①从存储方式上,nvarchar是按字符存储的,而varchar是按字节存储的;

     ②从存储量上考虑,varchar比较节省空间,因为存储大小为字节的实际长度,而nvarchar是双字节存储;

     ③在使用上,如果存储内容都是英文字符而没有汉字等其他语言符号,建议使用varchar;含有汉字的使用nvarchar,因为nvarchar是使用Unicode编码,即统一的字符编码标准,会减少乱码的出现几率;

     ④  如果你做的项目可能涉及不同语言之间的转换,建议用nvarchar。

3)如何使用这些类型?

如果你肯定存储的数据长度,而且不包中文的,可以选择char类型。

如果肯定存储的数据长度,但可能包括中文,可以选择nchar类型。

如果不确定存储的数据长度,存储只有英文、数字的最好用varchar

如果不确定存储的数据长度,也有可能有中文,可以选择nvarchar类型,在SQL Server2005中也是比较常用的字符数据类型

(4)Nvarchar优缺点:

 优点:判断字符串的时候可以不需要考虑中英文两种字符的差别,可以避免程  序中乱码的问题。

 缺点:存储英文字符会增大一倍的存储空间.但是在存储代价已经很低廉的情况下,优先考虑兼容性会给你带来更多好处的,效率没有varchar高。

 更多参考:varchar(n),nvarchar(n) 长度、性能、及所占空间分析

原文地址:https://www.cnblogs.com/peterYong/p/6556558.html