比较 MySQL varchar 和 IBM DB2 varchar 数据类型

Question

我对 MySQL varchar 数据类型有点怀疑。众所周知。

char 是固定长度的数据类型。因此，char 值的存储大小等于 列的最大大小。但是，在“varchar”的情况下，它是一个可变长度的数据类型， 因此，varchar 值的存储大小是输入数据的实际长度，而不是该列的最大大小。这就是为什么varchar 通常在需要存储字符/文本类型的数据并保留未使用的内存以供将来使用时更常用。

最近，我知道...对于 IBM DB2，如果您在表的其余列中间使用任何 varchar 列，那么该特定列中字符的存储大小等于varchar 列的原始大小。

EX：如果在一个表中有 3 列是这样的：

1. 名字：char(50)
2. 姓氏：varchar(50)
3. emailId : char(50)

所以，现在如果您想将此文本（'Majhi'）存储到数据类型为 varchar(50) 的列“lastName”中，那么它将占用完整的 50char 存储大小，而不是仅占用实际大小的 5chars的实际文本（'Majhi'）。

这就是为什么在 IBM DB2 中，包括任何 varchar 数据类型的 coloumn 位于表 whill 的其余列的中间也与 char 数据类型的工作方式相同。所以，内存优化不会发生。

所以，我只想知道我们的 MySQL 是否以相同的方式工作，或者它不会区分 varchar 数据类型列存在的位置并相应地工作，因为 varchar 数据类型列需要工作。

Answer 1

这里有两个方面。

第一个是磁盘存储。在这种情况下，对于每一行，只存储所需的数据，并且在 varchar 之后是否有任何其他列并不重要。

第二个是加载到内存中的表。在这种情况下，MySQL 在内部将VARCHAR(n) 转换为CHAR(m)[1]，其中m 是给定列中数据的最大长度。因此，如果您的列声明为VARCHAR(60)，但其中存储的最长字符串的长度为10，则内存中的字段将具有固定长度10。这导致在最小化内存占用和最大化数据访问性能之间进行折衷（如果您知道从哪里开始获取特定列会更容易）。

[1]：这里有点简化。它不是真正的 CHAR 或任何其他 MySQL 数据类型。