浅析MySQL里char、varchar、text的区别及应用场景
一、char、varchar、text的应用场景
在存储字符串时, 可以使用char、varchar或者text类型, 那么具体使用场景呢?
1、char长度固定, 即每条数据占用等长字节空间;适合用在身份证号码、手机号码等定。
2、varchar可变长度,可以设置最大长度;适合用在长度可变的属性。
3、text不设置长度, 当不知道属性的最大长度时,适合用text。
按照查询速度: char最快, varchar次之,text最慢。
1、char:char(n)中的n表示字符数,最大长度是255个字符; 如果是utf8编码方式, 那么char类型占255 * 3个字节。(utf8下一个字符占用1至3个字节)
2、varchar:varchar(n)中的n表示字符数,最大空间是65535个字节, 存放字符数量跟字符集有关系;
MySQL5.0.3以前版本varchar(n)中的n表示字节数;MySQL5.0.3以后版本varchar(n)中的n表示字符数;
varchar实际范围是65532或65533, 因为内容头部会占用1或2个字节保存该字符串的长度;如果字段default null(即默认值为空),整条记录还需要1个字节保存默认值null。
如果是utf8编码, 那么varchar最多存65532/3 = 21844个字符。
3、text:跟varchar基本相同, 理论上最多保存65535个字符, 实际上text占用内存空间最大也是65535个字节; 考虑到字符编码方式, 一个字符占用多个字节, text并不能存放那么多字符; 跟varchar的区别是text需要2个字节空间记录字段的总字节数。
由于varchar查询速度更快, 能用varchar的时候就不用text。
二、char、varchar、text的具体区别
最近有表结构设计中出现了varchar(10000)的设计引起了大家的讨论,我们下面就来分析分析。
1、首先普及一下常识:
(1)char(n)和varchar(n)括号中n代表字符的个数,并不代表字节个数,所以当使用了中文的时候(UTF8)意味着可以插入m个中文,但是实际会占用m*3个字节。
(2)同时char和varchar最大的区别就在于char不管实际value都会占用n个字符的空间,而varchar只会占用实际字符应该占用的空间+1,并且实际空间+1<=n。
(3)超过char和varchar的n设置后,字符串会被截断。
(4)char的上限为255字节,varchar的上限65535字节,text的上限为65535。
(5)char在存储的时候会截断尾部的空格,varchar和text不会。
(6)varchar会使用1-3个字节来存储长度,text不会。
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 |
总体来说:
1、char,存定长,速度快,存在空间浪费的可能,会处理尾部空格,上限255。
2、varchar,存变长,速度慢,不存在空间浪费,不处理尾部空格,上限65535,但是有存储长度实际65532最大可用。
3、text,存变长大数据,速度慢,不存在空间浪费,不处理尾部空格,上限65535,会用额外空间存放数据长度,顾可以全部使用65535。
2、应用场景的问题:
当 varchar(n) 后面的 n 非常大的时候,我们是使用 varchar 好,还是 text 好呢?
这是个明显的量变引发质变的问题。我们从2个方面考虑,第一是空间,第二是性能。
(1)首先从空间方面
从官方文档中我们可以得知当varchar大于某些数值的时候,其会自动转换为text,大概规则如下:
- 大于varchar(255)变为 tinytext
- 大于varchar(500)变为 text
- 大于varchar(20000)变为 mediumtext
所以对于过大的内容使用varchar和text没有太多区别。
(2)从性能方面
索引会是影响性能的最关键因素,而对于text来说,只能添加前缀索引,并且前缀索引最大只能达到1000字节。
而貌似varhcar可以添加全部索引,但是经过测试,其实也不是。由于会进行内部的转换,所以long varchar其实也只能添加1000字节的索引,如果超长了会自动截断。
localhost.test>create table test (a varchar(1500));
Query OK, 0 rows affected (0.01 sec)
localhost.test>alter table test add index idx_a(a);
Query OK, 0 rows affected, 2 warnings (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 2
localhost.test>show warnings;
+---------+------+---------------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------------+
| Warning | 1071 | Specified key was too long; max key length is 767 bytes |
| Warning | 1071 | Specified key was too long; max key length is 767 bytes |
+---------+------+---------------------------------------------------------+
从上面可以明显单看到索引被截断了。而这个767是怎么回事呢?这是由于innodb自身的问题,使用innodb_large_prefix设置。
从索引上看其实long varchar和text也没有太多区别。
所以我们认为当超过255的长度之后,使用varchar和text没有本质区别,只需要考虑一下两个类型的特性即可。(主要考虑text没有默认值的问题)
CREATE TABLE `test` (
`id` int(11) DEFAULT NULL,
`a` varchar(500) DEFAULT NULL,
`b` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
+----------+------------+-----------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------+
| 1 | 0.01513200 | select a from test where id=10000 |
| 2 | 0.01384500 | select b from test where id=10000 |
| 3 | 0.01124300 | select a from test where id=15000 |
| 4 | 0.01971600 | select b from test where id=15000 |
+----------+------------+-----------------------------------+
从上面的简单测试看,基本上是没有什么区别的,但是个人推荐使用varchar(10000),毕竟这个还有截断,可以保证字段的最大值可控,如果使用text那么如果code有漏洞很有可能就写入数据库一个很大的内容,会造成风险。
故,本着short is better原则,还是使用varchar根据需求来限制最大上限最好。
三、各个字段类型的存储需求
Data Type |
Storage Required |
1 byte |
|
2 bytes |
|
3 bytes |
|
4 bytes |
|
8 bytes |
|
FLOAT(p) |
4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53 |
4 bytes |
|
DOUBLE [PRECISION], REAL |
8 bytes |
DECIMAL(M,D), NUMERIC(M,D) |
Varies; see following discussion |
BIT(M) |
approximately (M+7)/8 bytes |
Data Type |
Storage Required Before MySQL 5.6.4 |
Storage Required as of MySQL 5.6.4 |
1 byte |
1 byte |
|
3 bytes |
3 bytes |
|
3 bytes |
3 bytes + fractional seconds storage |
|
8 bytes |
5 bytes + fractional seconds storage |
|
4 bytes |
4 bytes + fractional seconds storage |
Data Type |
Storage Required |
CHAR(M) |
M × w bytes, 0 <= M <= 255, where w is the number of bytes required for the maximum-length character in the character set |
BINARY(M) |
M bytes, 0 <= M <= 255 |
VARCHAR(M), VARBINARY(M) |
L + 1 bytes if column values require 0 – 255 bytes, L + 2 bytes if values may require more than 255 bytes |
L + 1 bytes, where L < 28 |
|
L + 2 bytes, where L < 216 |
|
L + 3 bytes, where L < 224 |
|
L + 4 bytes, where L < 232 |
|
ENUM('value1','value2',...) |
1 or 2 bytes, depending on the number of enumeration values (65,535 values maximum) |
SET('value1','value2',...) |
1, 2, 3, 4, or 8 bytes, depending on the number of set members (64 members maximum) |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
2020-06-03 实现粘性布局position:sticky
2018-06-03 IDEA是如何导入项目的,及启动导入项目遇到的问题:无法加载主类的一连串问题
2018-06-03 创建springBoot项目及启动报错遇到的问题解决:Failed to configure a DataSource: 'url' attribute is not specified and no embedd