Mysql数据库Char和Varchar字段类型长度的选择比较

  次阅读 作者:智能小宝 来源:互联网 2016-01-28 13:02 我要评论(0)

网上有很多关于char和varchar的相关比较,但是都历史悠久,这里转载一篇信息比较新的,个人认为对我的设计字段决定帮助很大。

现代数据库一般都支持CHAR与VARCHAR字符型字段类型,CHAR是用来保存定长字符,存储空间的大小为字段定义的长度,与实际字符长度 无关,当输入的字符小于定义长度时最后会补上空格。VARCHAR是用来保留变长字符,在数据库中存储空间的大小是实际的字符长度,不会像CHAR一样补 上空格,这样占用的空间更少。

从以上特点来看,VARCHAR比CHAR有明显的优势,因此大部份数据库设计时都应该采用VARCHAR类型。那为什么还需要CHAR类型 呢,个人认为有以下几个原因:

1、为了跟以前版本的数据库进行一个兼容,因为很久以前数据库只支持CHAR类型,有些应用的业务逻辑也只是针对CHAR类型设计的,所以数据 库软件也就一直保留CHAR类型。

2、CHAR类型是定长的,一些数据库可以在每条记录中不存储字段长度信息,这样可以节省部份空间,也可以方便做一些内存对齐提高性能,但个人 认为这带来的性能提升非常微小,至少ORACLE数据库是没有意义的。

3、还有说法是有些数据经常修改,长度可能变化,会引起碎片,采用CHAR就不会产生碎片,这个说法比较多,但我认为既然长度会变化,那用 VARCHAR更能节省内存与存储空间来提升性能,只要数据块预留的空间没有问题,采用VARCHAR性能更好。

对于ORACLE数据库,我找不到充足的理由来使用CHAR类型,而且CHAR还会带来讨厌的空格,有些文章说MYSQL的MYISAM存储引 擎在和长度固定的情况下CHAR比VARCHAR好,这个没有测试过,不太了解。

由于VARCHAR是变长存储,那么很多人会有疑问,比如STATUS字段定义VARCHAR(10)与VARCHAR(1000)有什么区 别,反正是变长的,存储空间都一样,省得以后要加长又要改变字段定义。 下面说一下我的理解:

1、字段长度是数据库一种约束,可以保证进入数据库的数据符合长度要求,定义合理的字段长度可以减少一部份非法数据进入,比如:我们业务中 STATUS只有 NEW , DELETE , CLOSE 3种状态,使用VARCHAR(5)保存,这样可以有效的减少非法数据进入,定义合理的长 度也可以让人容易理解字段的用途,试想一下,如果你所有的字符字段长度都是VARCHAR(4000)会是什么样的情况。

2、VARCHAR的字段长度虽然对数据存储没有太大影响,但对特定的数据库还是有一些细微差别,比如MYSQL中定义的长度如果小于255, 字段长度用1个字节表示,如果超过255,字段的长度将固定用2个字节表示。如果你的业务数据最大长度只有10,但定义长度为256则每条记录会多浪费了 一个字节来存储长度。ORACLE没有这样的问题,它会根据每条记录字段的实际长度动态选择长度标识。

3、字段定义的长度对索引也有较大影响。ORACLE对索引长度还是有一定限制,8i官方文档说明单条记录索引信息的长度不能超过数据块大小的 40%,9i中是75%,实际上也差不多,具体可以见jametong的http://www.dbthink.com/?p=20这篇文档,里面有详细 的测试结果。如果你的数据块大小是8K,那么索引字段的定义长度不能超过6398,比如,你要给表上2个VARCHAR(4000)字段建组合索引,创建 时会直接报错。另外索引组织表及在线重建索引(因为中间会临时创建一个索引组织表)允许的索引信息长度更小,只能是数据块大小的40%,实际中8K的数据 块大小,要使用在线重建索引,那定义的长度不能超过3215。从以上可以看出,数据块大小为8K时,设计字段时如果要定义为VARCHAR(4000), 那这个字段就不能考虑建立索引,因为即使能建上,也不能做在线重定义操作,DBA要进行索引维护时只能停止应用,这将对系统的可用性产生较大影响。关于 ORACLE索引长度限制测试的脚本如下:

[sql] view plaincopy

SQL> create table test1

2 (

3 c1 varchar2(4000),

4 c2 varchar2(4000),

5 c3 varchar2(4000)

6 )

7 ;

Table created

SQL> create index test1_ind1 on TEST1 (c1);

Index created

SQL> alter index test1_ind1 rebuild online;

alter index test1_ind1 rebuild online

ORA-00604: error occurred at recursive SQL level 1

ORA-01450: maximum key length (3215) exceeded

SQL> create index test1_ind2 on TEST1 (c2, c3);

create index test1_ind2 on TEST1 (c2, c3)

ORA-01450: maximum key length (6398) exceeded

本站文章信息来源于网络以及网友投稿,本站只负责对文章进行整理、排版、编辑,是出于传递更多信息之目的,并不意味着赞同其观点或证实其内容的真实性。如果您有什么意见或建议,请联系QQ28-1688-302!

人工智能实验室
相关文章相关文章
  • 英国研发“杀生”机器人 通过生命体获取能量

    英国研发“杀生”机器人 通过生命体获取能量

  • 韩春雨称已能重复实验结果 近期将有消息公布

    韩春雨称已能重复实验结果 近期将有消息公布

  • 无人驾驶汽车如何改变城市生活?听听他们怎么说

    无人驾驶汽车如何改变城市生活?听听他们怎么说

  • 未来两年人工智能要怎么走?看这篇就够了

    未来两年人工智能要怎么走?看这篇就够了

网友点评网友点评
阅读推荐阅读推荐

据国外媒体报道,在过去两年内,聊天机器人(chatbot)、人工智能以及机器学习的研发和采用取得了巨大进展。许多初创公司正利用人工智能和...

霍金 视觉中国 图 英国著名物理学家霍金(Stephen Hawking)再次就人工智能(AI)发声,他认为:对于人类来说,强大AI的出现可能是最美妙的...

文|郑娟娟 今年,人工智能(AI) 60岁了。在AI60岁的时候,笔者想要介绍一下AI100,一个刚刚2岁的研究项目,但它的预设寿命是100年,甚至更长...

AlphaGo与李世石的人机大战,为大众迅速普及了人工智能的概念。 但对谷歌而言,除了下围棋,现在的人工智能进展到哪一步了?未来,人工智能...