Home >Database >Mysql Tutorial >char、varchar、varchar2区别

char、varchar、varchar2区别

WBOY
WBOYOriginal
2016-06-07 15:09:342017browse

char varchar varchar2 的区别 区别: 1.CHAR的长度是固定的,而VARCHAR2的长度是可以变化的, 比如,存储字符串“abc,对于CHAR (20),表示你存储的字符将占20个字节(包括17个空字符),而同样的VARCHAR2 (20)则只占用3个字节的长度,20只是最大,当你存储的

char varchar varchar2 的区别 
区别:
1.CHAR的长度是固定的,而VARCHAR2的长度是可以变化的, 比如,存储字符串“abc",对于CHAR (20),表示你存储的字符将占20个字节(包括17个空字符),而同样的VARCHAR2 (20)则只占用3个字节的长度,20只是最大值,当你存储的字符小于20时,按实际长度存储。 
2.CHAR的效率比VARCHAR2的效率稍高。 
3.目前VARCHAR是VARCHAR2的同义词。工业标准的VARCHAR类型可以存储空字符串,但是oracle不这样做,尽管它保留以后这样做的权利。Oracle自己开发了一个数据类型VARCHAR2,这个类型不是一个标准的VARCHAR,它将在数据库中varchar列可以存储空字符串的特性改为存储NULL值。如果你想有向后兼容的能力,Oracle建议使用VARCHAR2而不是VARCHAR。

何时该用CHAR,何时该用varchar2? 
CHAR与VARCHAR2是一对矛盾的统一体,两者是互补的关系. 
VARCHAR2比CHAR节省空间,在效率上比CHAR会稍微差一些,即要想获得效率,就必须牺牲一定的空间,这也就是我们在数据库设计上常说的‘以空间换效率’。 
VARCHAR2虽然比CHAR节省空间,但是如果一个VARCHAR2列经常被修改,而且每次被修改的数据的长度不同,这会引起‘行迁移’(Row Migration)现象,而这造成多余的I/O,是数据库设计和调整中要尽力避免的,在这种情况下用CHAR代替VARCHAR2会更好一些。

char varchar nchar nvarchar 四者的区别
1、char[(n)]

长度为 n 个字节的固定长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为 n 个字节。char 在 SQL-92 中的同义词为 character。

2、varchar[(n)]


长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度,而不是 n 个字节。所输入的数据字符长度可以为零。varchar 在 SQL-92 中的同义词为 char varying 或 character varying。


如果没有在数据定义或变量声明语句中指定 n,则默认长度为 1。如果没有使用 CAST 函数指定 n,则默认长度为 30。


将为使用 char 或 varchar 的对象被指派数据库的默认排序规则,除非用 COLLATE 子句另外指派了特定的排序规则。该排序规则控制用于存储字符数据的代码页。


支持多语言的站点应考虑使用 Unicode nchar 或 nvarchar 数据类型以尽量减少字符转换问题。如果使用 char 或 varchar: 


如果希望列中的数据值大小接近一致,请使用 char。




如果希望列中的数据值大小显著不同,请使用 varchar。 
如果执行 CREATE TABLE 或 ALTER TABLE 时 SET ANSI_PADDING 为 OFF,则一个定义为 NULL 的 char 列将被作为 varchar 处理。 


当排序规则代码页使用双字节字符时,存储大小仍然为 n 个字节。根据字符串的不同,n 个字节的存储大小可能小于 n 个字符。

nchar 是固定长度 Unicode 数据的数据类型,nvarchar 是可变长度 Unicode 数据的数据类型,二者均使用 UNICODE UCS-2 字符集。
3、nchar(n)

包含 n 个字符的固定长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。存储大小为 n 字节的两倍。nchar 在 SQL-92 中的同义词为 national char 和 national character。

3、nvarchar(n)

包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。nvarchar 在 SQL-92 中的同义词为 national char varying 和 national character varying。

如果没有在数据定义或变量声明语句中指定 n,则默认长度为 1。如果没有使用 CAST 函数指定 n,则默认长度为 30。


如果希望列中所有数据项的大小接近一致,则使用 nchar。


如果希望列中数据项的大小差异很大,则使用 nvarchar。


使用 nchar 或 nvarchar 的对象被赋予数据库的默认排序规则,除非使用 COLLATE 子句赋予特定的排序规则。


SET ANSI_PADDING OFF 不适用于 nchar 或 nvarchar。SET ANSI_PADDING ON 永远适用于 nchar 和 nvarchar。


===========================================================================

nchar(n)     


    包含     n     个字符的固定长度     Unicode     字符数据。n     的值必须介于     1     与     4,000     之间。存储大小为     n     字节的两倍。nchar     在     SQL-92     中的同义词为     national     char     和     national     character。    


    nvarchar(n)    


    包含     n     个字符的可变长度     Unicode     字符数据。n     的值必须介于     1     与     4,000     之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。nvarchar     在     SQL-92     中的同义词为     national     char     varying     和     national     character     varying。   


    注释  


    如果没有在数据定义或变量声明语句中指定     n,则默认长度为     1。如果没有使用     CAST     函数指定     n,则默认长度为     30。    


    如果希望列中所有数据项的大小接近一致,则使用     nchar。    


    如果希望列中数据项的大小差异很大,则使用     nvarchar。    


    使用     nchar     或     nvarchar     的对象被赋予数据库的默认排序规则,除非使用     COLLATE     子句赋予特定的排序规则。    


    SET     ANSI_PADDING     OFF     不适用于     nchar     或     nvarchar。SET     ANSI_PADDING     ON     永远适用于     nchar     和     nvarchar。   
   二、char     和     varchar  
    固定长度     (char)     或可变长度     (varchar)     字符数据类型。    

    char[(n)]    


    长度为     n     个字节的固定长度且非     Unicode     的字符数据。n     必须是一个介于     1     和     8,000     之间的数值。存储大小为     n     个字节。char     在     SQL-92     中的同义词为     character。     

    varchar[(n)]  
    长度为     n     个字节的可变长度且非     Unicode     的字符数据。n     必须是一个介于     1     和     8,000     之间的数值。存储大小为输入数据的字节的实际长度,而不是     n     个字节。所输入的数据字符长度可以为零。varchar     在     SQL-92     中的同义词为     char     varying     或     character     varying。  
    注释  
    如果没有在数据定义或变量声明语句中指定     n,则默认长度为     1。如果没有使用     CAST     函数指定     n,则默认长度为     30。  

    将为使用     char     或     varchar     的对象被指派数据库的默认排序规则,除非用     COLLATE     子句另外指派了特定的排序规则。该排序规则控制用于存储字符数据的代码页。    

    支持多语言的站点应考虑使用     Unicode     nchar     或     nvarchar     数据类型以尽量减少字符转换问题。如果使用     char     或     varchar:      

    如果希望列中的数据值大小接近一致,请使用     char。   

    如果希望列中的数据值大小显著不同,请使用     varchar。    


    如果执行     CREATE     TABLE     或     ALTER     TABLE     时     SET     ANSI_PADDING     为     OFF,则一个定义为     NULL     的     char     列将被作为     varchar     处理。

    当排序规则代码页使用双字节字符时,存储大小仍然为     n     个字节。根据字符串的不同,n     个字节的存储大小可能小于     n     个字符。  


总结:
   1、 varchar:  
              可变长度的非    Unicode   数据,最长为    8,000    个字符。  
   2、nvarchar:  
              可变长度    Unicode    数据,其最大长度为    4,000    字符。  
   3、char:
          固定长度的非 Unicode 字符数据,最大长度为 8,000 个字符。
   4、nchar
         固定长度的 Unicode 数据,最大长度为 4,000 个字符。

    5、     char和varchar都是字符串类型的

        用Unicode编码的字符串,结果是字符的整数值


================================================================================================================================

char是定长的,varchar是变长的。

varchar2应该是varchar的升级,似乎只有ORACLE才有,这里不作讨论。

char定长存储,速度快,但是存在一定的空间浪费,适用于字段不是很大,对速度要求高的场合。速度快是因为其在物理上是按定长存储的,这样,就可以根据偏移址一次取出固定长度的字符。

varchar变长存储,所以效率不如char。varchar在存储时,在物理上要先存储该字段的实际长度,然后才是内容。这样读取的时候,就要读取两次,一次读它的长度,然后才是内容。所以它的访问速度会比char慢一些。但它可以节省空间。 

由于mysql自身的特点,如果一个数据表存在varchar字段,则表中的char字段将自动转为varchar字段。在这种情况下设置的char是没有意义的。所以要想利用char的高效率,要保证该表中不存在varchar字段;否则,应该设为varchar字段。

 

SQL中char、varchar、text和nchar、nvarchar、ntext的区别
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个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。
所以一般来说,如果含有中文字符,用nchar/nvarchar,如果纯英文和数字,用char/varchar。

 

------------------------

数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢?

 

数据库定义到char类型的字段时,不知道大家是否会犹豫一下,到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢?结果很可能是两种,一种是节俭人士的选择:最好是用定长的,感觉比变长能省些空间,而且处理起来会快些,无法定长只好选用定长,并且将长度设置尽可能地小;另一种是则是觉得无所谓,尽量用可变类型的,长度尽量放大些。
鉴于现在硬件像萝卜一样便宜的大好形势,纠缠这样的小问题实在是没多大意义,不过如果不弄清它,总觉得对不起劳累过度的CPU和硬盘。

下面开始了(以下说明只针对SqlServer有效):
1、当使用非unicode时慎用以下这种查询:
select f from t where f = N'xx'
原因:无法利用到索引,因为数据库会将f先转换到unicode再和N'xx'比较
2、char 和相同长度的varchar处理速度差不多(后面还有说明)
3、varchar的长度不会影响处理速度!!!(看后面解释)
4、索引中列总长度最多支持总为900字节,所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引
5、text、ntext上是无法创建索引的
6、O/R Mapping中对应实体的属性类型一般是以string居多,用char[]的非常少,所以如果按mapping的合理性来说,可变长度的类型更加吻合
7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式,而这种方式是无法利用索引的,所以如果对于此种字段,索引建了也白建
8、其它一些像remark的字段则是根本不需要查询的,所以不需要索引
9、varchar的存放和string是一样原理的,即length {block}这种方式,所以varchar的长度和它实际占用空间是无关的
10、对于固定长度的字段,是需要额外空间来存放NULL标识的,所以如果一个char字段中出现非常多的NULL,那么很不幸,你的占用空间比没有NULL的大(但这个大并不是大太多,因为NULL标识是用bit存放的,可是如果你一行中只有你一个NULL需要标识,那么你就白白浪费1byte空间了,罪过罪过!),这时候,你可以使用特殊标识来存放,如:'NV'
11、同上,所以对于这种NULL查询,索引是无法生效的,假如你使用了NULL标识替代的话,那么恭喜你,你可以利用到索引了
12、char和varchar的比较成本是一样的,现在关键就看它们的索引查找的成本了,因为查找策略都一样,因此应该比较谁占用空间小。在存放相同数量的字符情况下,如果数量小,那么char占用长度是小于varchar的,但如果数量稍大,则varchar完全可能小于char,而且要看实际填充数值的充实度,比如说varchar(3)和char(3),那么理论上应该是char快了,但如果是char(10)和varchar(10),充实度只有30%的情况下,理论上就应该是varchar快了。因为varchar需要额外空间存放块长度,所以只要length(1-fillfactor)大于这个存放空间(好像是2字节),那么它就会比相同长度的char快了。
13、nvarchar比varchar要慢上一些,而且对于非unicode字符它会占用双倍的空间,那么这么一种类型推出来是为什么呢?对,就是为了国际化,对于unicode类型的数据,排序规则对它们是不起作用的,而非unicode字符在处理不同语言的数据时,必须指定排序规则才能正常工作,所以n类型就这么一点好处。


总结:
1、如果数据量非常大,又能100%确定长度且保存只是ansi字符,那么char
2、能确定长度又不一定是ansi字符或者,那么用nchar;
3、不确定长度,要查询且希望利用索引的话,用nvarchar类型吧,将它们设到400;
4、不查询的话没什么好说的,用nvarchar(4000)
5、性格豪爽的可以只用3和4,偶尔用用1,毕竟这是一种额外说明,等于告诉别人说,我一定需要长度为X位的数据


Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn