MySQL中CHAR and VARCHAR

MySQL版本:8.0版本

CHARVARCHAR类型相似,但在存储、检索方式、最大长度和是否保留末尾空格四个方面存在差异。

长度:

  • CHAR(0-255)

    类型为CHAR的列的长度是固定的,可以在创建表时指定该长度。比如列的定义为CHAR(30),则该列最多可以存储30个字符。

  • VARCHAR(0-65535)

    类型为VARCHAR的列的长度是可变的,在创建表时指定的长度为最大长度,最大长度的值受行最大长度的限制和使用的编码字符。比如列的类型为VARCHAR(512),则该列最多可以存储512个字符。

存储:

  • CHAR

    由于CHAR类型的列的长度是固定的,如果插入的值的长度小于定义的长度,则会在插入值的末尾添加空格以确保值的长度恰好等于定义的长度。如果没有开启严格SQL模式,如果插入值的长度超过列允许的最大长度,值将会被截断以确保满足长度要求并产生一个告警。通过开启严格的SQL模式,对非空字符的截断将产生一个错误而不是告警并抑制值的插入。

  • VARCHAR

    VARCHAR是变长字符串;VARCHAR存储时不会使用空格填充;VARCHAR存储包括两部分:1或2字节的前缀(表示数据的长度)和数据。如果存储的数据的字节数不超过255则使用1个字节的前缀;如果存储的长度超过255字节则使用2字节长度的前缀。无论使用哪种SQL模式,截断超过VARCHAR类型的空格都将产生一个告警。

检索方式:

  • CHAR

    当检索CHAR列的值时,如果没有开启PAD_CHAR_TO_FULL_LENGTH SQL模式,则会移除尾部的空格。

  • VARCHAR

    根据标准SQL,在存储和检索值时保留尾部空格。

样例:

下面的表格通过存储不同的字符串到CHAR(4)和VARCHAR(4)类型的列中展示了CHAR和VARCHAR之间的不同。

Value CHAR(4) Storage Required VARCHAR(4) Storage Required
'' ' ' 4 bytes '' 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes

表格最终一行是实际存储占用的空间(未开启严格SQL模式),如果启用严格SQL模式,超过列长度的值将不会被存储并产生一个错误。

InnoDB将长度大于或等于768字节的固定长度字段编码为可变长度字段,这样可以使用off-page存储。例如如果字符占用超过3个字节,那么一个类型为CHAR(255)的列的长度可能超过768字节。

将同一个给定值存储在CHAR(4)和VARCHAR(4)列中,则从这些列检索的值并不总是相同的,因为检索时会从CHAR列中删末尾空格。以下示例说明了这种差异:

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO vc VALUES ('ab  ', 'ab  ');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+
| (ab  )              | (ab)                |
+---------------------+---------------------+
1 row in set (0.06 sec)

CHAR,VARCHAR和TEXT列中的值根据分配给该列的字符集排序规则进行排序和比较。

字符串比较规则

MySQL排序规则有一个名为 PAD SPACE的属性,但基于UCA 9.0.0及更高版本的Unicode排序规则除外(属性的值为NO PAD)。

可以从INFORMATION_SCHEMA.COLLATIONS表中获取每种排序规则的pad属性:

SELECT * FROM COLLATIONS

对于非二进制字符串(CHAR,VARCHAR,TEXT),字符串排序规则中的pad属性决定字符串末尾的空格在字符串比较中的处理方式。拥有NO PAD 值的字符串排序规则将尾部的空格视作其他字符,参与到字符串的比较中。拥有PAD SPACE 值的字符串排序规则将忽略字符串尾部的空格,这些空格不参与字符的比较。服务器SQL模式对尾随空格的比较行为没有影响。

对于字符串尾部空格被截断而且不参与字符串比较的情况,如果一个字段上拥有唯一索引,如果插入该类的值仅存在尾部的空格数不同的差异,这将产生一个重复key的错误。

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

推荐阅读更多精彩内容