MySQL 数据表优化设计(三):CHAR 和 VARCHAR 怎么选?

MySQL 数据表优化设计(三):CHAR 和 VARCHAR 怎么选?,第1张

VARCHAR 和 CHAR 是两种主要的字符串类型,用于存储字符。不幸的是,由于实现的方式依赖于存储引擎,因此很难解释这些字符串在磁盘和内存中如何存储,除了除了常用的 InnoDB 和 MyISAM 外,假设你使用了其他存储引擎,应当仔细阅读存储引擎的文档。

VARCHAR 存储可变长度的字符串,也是最常用的字符数据类型。相比固定长度的类型,VARCHAR 所需的存储空间更小,它会尽可能少地使用存储空间(例如,短的字符串占据的空间)。对于 MyISAM 来说,如果创建表的时候指定了 ROW_FORMAT=FIXED 的话,那么会使用固定的空间存储字段而导致空间浪费。VARCHAR 使用1-2个额外的字节存储字符串的长度:当最大长度低于255字节的时候使用1个字节,如果更多的话就使用2个字节。因此,拉丁字符集的 VARCHAR(10)会使用11个字节的存储空间,而 VARCHAR(1000)则会使用1002个字节的存储空间。

VARCHAR 由于能够节省空间,因此可以改善性能。但是,由于长度可变,当更新数据表的时候数据行的存储空间会变化,这一定程度上会带来额外的开销。如果数据行的长度导致原有的存储位置无法存放,那么不同的存储引擎会做不同的处理。例如 MyISAM 可能产生数据行的碎片,而 InnoDB 需要进行磁盘分页来存放更新后的数据行。

通常,如果最大的列长度远远高于平均长度的话(例如可选的备注字段),使用 VARCHAR 是划算的,同时如果更新的频次很低,那么碎片化也不会是一个问题。需要注意的是,如果使用的是 UTF-8字符集,则实际存储的字节长度是根据字符定的。对于中文,推荐的存储字符集是 utf8mb4。

CHAR 类型的长度是固定的,MySQL 会对每个字段分配足够的存储空间。 存储CHAR 类型值的时候,MySQL 会移除后面多出来的空字符 。值是使用空字符进行对齐以便进行比较。对于短的字符串来说,使用 CHAR 更有优势,而如果所有的值的长度几乎一致的话,就可以使用 CHAR。例如存储用户密码的MD5值时使用 CHAR 就更合适,这是因为 MD5的长度总是固定的。同时,对于字段值经常改变的数据类型来说,CHAR 相比 VARCHAR 也更有优势,因为 CHAR 不会产生碎片。对于很短的数据列,使用 CHAR 比 VARCHAR更高效,例如使用CHAR(1)存储逻辑值的 Y 和 N,这种情况下只需要1个字节,而 VARCHAR 需要2个字节。

对于移除空字符这个特性会感觉奇怪,我们举个例子:

按上面的结果插入数据表后,string2中的前置空格不会移除,但使用 CHAR 类型存储时,string3尾随空格会被移除,使用 SQL 查询结果来检验一下:

得出来的结果如下,可以看到 CHAR 类型的 string3后面的空格被移除了,而 VARCHAR类型的没有。这种情况大多数时候不会有什么问题,实际在应用中也经常会使用 trim 函数移除两端的空字符,但是如果确实需要存储空格的时候,那就需要注意不要选择使用 CHAR 类型:

数据如何存储是由存储引擎决定的,而且存储引擎处理固定长度和可变长度的数据的方式并不相同。Memory 引擎使用固定大小的行,因此它需要分配最大可能的存储空间——即便数据长度是可变的。但是,对于字符串的对齐和空字符截断是由 MySQL 服务端完成的,因此所有存储引擎都是一样的。

与 CHAR 和 VARCHAR 相似的是 BINARY和 VARBINARY,用于存储二进制字节字符,BINARY 的对齐使用字符0的字节值来对齐,并且再获取值的时候不会截断。如果需要使用字符的字节值而不是字符的话,使用 BINARY 会更高效,这是因为比较时,一方面不需要考虑大小写,另一方面是MySQL一次只比较一个字节。

1.建立用户信息表

create table userinfo(id int(4) not null primary key, name varchar(20) not null unique key)engine=innodb default charset=utf8

2.建立好友关系表

create table friend(uid int(4) not null, foreign key(uid) references

userinfo(id),fid int(4) not null, foreign key(fid) references

userinfo(id),unique key(uid,fid))engine=innodb default charset=utf8

3.追加测试数据(满足uid<fid条件)

insert userinfo values(1111---9999,'namea---namei’)

insert friend values(1111,4444---6666)

insert friend values(5555,6666---9999)

4.查询好友(5555的好友)

select * from friend where uid=5555 or fid=5555

+-------+------+

| uid | fid|

+-------+------+

| 1111 | 5555 |

| 5555 | 6666 |

| 5555 | 7777 |

| 5555 | 8888 |

| 5555 | 9999 |

+-------+--------+

5.问题:

5.1.userinfo中的id和name不为null,且不可重复:table设计可以做到

5.2.friend中的uid和fid均不为null,且都来自于userinfo的id:table设计可以实现

5.3.(uid,fid)组合不可重复:table设计可以完成

5.4.好友关系的表达时,(1111,5555)和(5555,1111)有冗余,也会出现(1111,1111)这样的数据:这个在table设计实现比较麻烦,需要在程序层面实现,也即增加限制条件uid<fid即可

6.结果:

table设计达不到要求,或者较难达到要求时,可以在程序层面予以弥补。

选中某个表,然后右键点击,选择“设计表”即可。

也可以左键点击某个表(即选中某表),在上面辅助菜单栏里有“打开表”、“设计表”、“新建表”等按钮可点击,点击“设计表”按钮即可。

进入后,会d出新的 *** 作窗口,新窗口的菜单栏里有常用的修改表结构的按钮,右键点击某列字段也可以d出相应的修改表的 *** 作按钮。

其它摸索着看提示 *** 作即可,还是很简单的。

修改好表后点击菜单栏上的“保存”按钮即可。

注:若要查看修改表的sql语句,必须在“保存”之前点击“SQL预览”按钮。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6116337.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-15
下一篇 2023-03-15

发表评论

登录后才能评论

评论列表(0条)

保存