mysql中char与varchar的区别分析

听你说的话听起来很复杂。
刚开始学习MySQL的时候，我很困惑。

我记得那年我在网站幕后帮助一位朋友，他坚持让我将用户配置文件设置为 CHAR (2 5 5 )，我认为这是无辜的。
结果怎么样？很多用户写短评论，我都得手动给他们加空格，不然最后会有很多空格，看起来很奇怪。
数据表很大，存储起来很浪费空间。
后来我改成了VARCHAR(2 5 5 )。
现在好多了。
用户写多少空间就写多少，非常干净。

此外，如果字符串特别长，则 VARCHAR 两字节长度标签与总空间相比是微不足道的。
但如果您使用 CHAR(1 )，则无论是否使用该字符，我们都需要为其节省空间。
我有一个项目来创建固定格式的数字，例如身份证号码。
CHAR(1 8 ) 最适合，一个字符一个字节，对齐。
如果使用VARCHAR(1 8 )，如果某个字段不小心填满了半个字以上，就必须加上两个长度字节，非常不方便。

所以你看，CHAR 具有固定长度，非常适合存储 ID 号和邮政编码等固定长度数据。
VARCHAR 长度可变，非常适合存储可变长度数据，例如用户名、评论等。
如果您没有大量数据，您可能会意外使用它，并且性能影响不会明显。
但如果数据量很大，就需要平衡空间和性能。

这些都是我在现实生活中遇到的陷阱，我不会处理那些愚蠢的理论。
如果你清楚地了解场景，你还是不知道该用什么？

char、varchar、varchar2、nvarchar2、nvarchar的区别与使用

说实话，刚入行的时候，谈论数据库字符类型是一件非常头疼的事情。
Char、varchar 和 nvarchar 看起来都很相似，但使用起来非常复杂。
可能有点极端，但绝对是基于陷阱的。

首先我们来谈谈char(n)。
这个问题最烦人的就是固定长度。
我在旧系统上看到过它，当时使用 char(1 0) 来存储用户名。
结果出现了一个叫“Jangsan”的好友，系统直接切到了“Jangsan”，留下了6 个空位。
我还在愚蠢地填补数据库中的空白，当我最终检查时，我以为这个人叫“Jangsan”。
您知道您打印的图像是否丑陋吗？那么 char(n) 适合在哪里呢？以严格固定的长度存储内容，例如状态码、ID 号等。
但是，如果你想存储注释等，使用 char(n) 基本上会导致问题。

我们来谈谈varchar/varchar2 这是我用得最多的。
它有各种长度，没有边距，非常舒适。
例如，在保存用户注释时，有些人写“今天天气很好”，而另一些人则写“项目需求已经讨论了很长时间”。
它们有不同的长度，varchar 非常适合。
Oracle 人员提出 varchar2 主要是为了用 null 替换空字符串，以避免在 varchar 中将“''”与 null 混淆的陷阱。
在 Oracle 环境中工作时，强烈建议使用 varchar2 处理空值的逻辑更加清晰。

有趣的是 nvarchar/nvarchar2 两者都是基于Unicode的，所以中文和英文都是以字节来计算的。
它对于存储汉字特别友好。
“你好”是2 个字节。
它不像char那样算作2 个字节，但存储“abc”也占用2 个字节。
这在多语言环境中特别有用。
我曾经在外贸系统上工作，由于客户名称可能是西班牙语或日语，所以 nvarchar2 就可以了。
但缺点是每个字符占用固定的空间，存储大量的英文文本可能比varchar浪费更多的存储空间。

varchar 和 nvarchar 有什么区别？说白了，就是存中文还是英文。
如果你的系统是全中文的，nvarchar2 是一个不错的选择。
如果一切都是英文，则 varchar2 可以节省更多空间。
我有一个项目，设计数据库的时候没有说清楚这一点。
结果保存中文数据的时候，所有的varchar字段都被破坏了。
我最终加班修复了数据库。
我不想提及那种感觉。

最后我们来谈谈长度分配。
char(n) n 的最大大小为 8 000 字节，但不要设置得太大。
我见过人们使用 char(4 000) 来存储文本，而索引却慢得像蜗牛。
对于varchar和nvarchar，Oracle的varchar2 和nvarchar2 ，n的范围是1 到4 000，最大为2 ^3 1 -1 但不要轻易使用 max。
使用它的人我知道结果。

我没有直接运行过，但我记得数据是nvarchar2 中文和英文也占用2 个字节。
详细信息将根据您的数据库实现而有所不同。
但这个原则是正确的。
如果需要多语言支持，请使用 nvarchar 系列。
如果长度固定且不包含汉字，则使用char。
在其他情况下，它默认为 varchar2 (Oracle) 或 varchar (其他)。

建立SQL数据库，其中有个身份证的字段，该用什么数据类型。

公平地说，使用 char(1 8 ) 来存储 ID 号确实是设计自定义表时的常见选择。
I used to do this in the financial system.当时主要考虑的是固定的ID号长度。
1 8 个字符，不多也不少，与char类型完美匹配，无需额外处理长度问题。

有趣的是char类型的特性。
例如char(1 0)，无论你存储“1 2 3 ”还是“hello”，都会占用1 0个字节，这不足以填充空格。
这个固定长度的函数确实简化了一些操作。
我记得我们的系统需要通过ID号快速搜索用户。
使用 char 类型对于索引来说非常强大，并且查找起来特别有趣。

但我一直发现 char 和 varchar 之间的权衡非常有趣。
扩展信息中提到的所有要点我都亲身经历过。
例如，在另一个旧项目中，我们有一个带有 char(5 0) 字符的名称字段。
后来我们发现，随着用户数量的增加，改变字段长度需要很长时间。
改用varchar后，扩展就不太方便了。
我当时和团队争论说，虽然char在存储数据时是固定长度的，但是它的可扩展性太差了，可能有点极端。
后来运维的人直接抱怨我们选类型没有考虑未来，哈哈。

关于 NULL 值的另一个有趣的点。
NULL char 列值实际上占用空间。
上次接手旧系统的时候，差点就因此惹上麻烦。
你有一个char(2 0)地址字段并且大量的NULL值导致表的大小莫名其妙的增长并且数据查询仍然很慢。
后来我用varchar(2 5 5 )解决了这个问题。
在数据量大的场景中，这些额外的开销确实不容忽视。

就插入效率而言，char确实不如varchar。
我记得有一天我正在做性能测试，我插入了大量带有 NULL 值的字符列，这让我质疑自己的生活。
而且 varchar 更快，因为 NULL 不占用空间。
所以现在，除非是绝对固定长度的数据，比如 ID 号，否则我通常使用 varchar。

但是在索引效率方面，char有优势。
我之前在电子商务系统中测试过这一点。
也是按照ID号进行索引，char类型的查询速度显然更快。
当然，这是特定于数据库和版本的，不能一概而论。

一般情况下选择char还是varchar要根据情况而定。
对于固定长度ID号、频繁查询等业务场景，char确实是一个不错的选择。
但对于其他字段，尤其是那些可能变得更长的字段，使用varchar更加灵活，并且提供了更好的可扩展性。
我个人并没有经营过该领域的所有类型的业务。
我记得关于X的数据，但我建议你检查你的特定系统的性能测试结果。