char varchar varchar2 的区别 (转)

char varchar varchar2 的区别 http://blog.csdn.net/honglei_zh/article/details/7172538
区别:
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位的数据

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,921评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,635评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,393评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,836评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,833评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,685评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,043评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,694评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,671评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,670评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,779评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,424评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,027评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,984评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,214评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,108评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,517评论 2 343

推荐阅读更多精彩内容