VARCHAR 和 CHAR
VARCHAR 和 CHAR 是两种最主要的字符串类型。
每个字符串列可以有自己的字符集和该字符集的排序规则集。
存储引擎在内存中存储 CHAR 或 VARCHAR 值的方式可能与在磁盘上存储该值的方式不同,并且服务器在从存储引擎检索该值时可能会将其转换为另一种存储格式。
VARCHAR
VARCHAR 用于存储可变长度的字符串,是最常见的字符串数据类型。它比固定长度的类型更节省空间,因为它仅使用必要的空间。
VARCHAR 需要额外使用 1 或 2 字节记录字符串的长度:
如果列的最大长度小于或等于 255 字节,则只使用 1 字节表示
否则使用 2 字节
假设采用 latin1 字符集,一个 VARCHAR(10) 的列需要 11 字节的存储空间。VARCHAR(1000) 的列则需要 1002 个字节,因为需要 2 字节存储长度信息。
VARCHAR 节省了存储空间,所以对性能也有帮助。但是,由于行是可变长度的,在更新时可能会增长,这会导致额外的工作。如果行的增长使得原位置无法容纳更多内容,则处理行为取决于所使用的存储引擎。例如,InnoDB 可能需要分割页面来容纳行。
下面这些情况使用 VARCHAR 是合适的:
字符串列的最大长度远大于平均长度;
列的更新很少,所以碎片不是问题;
使用了像 UTF-8 这样复杂的字符集,每个字符都使用不同的字节数进行存储。
慷慨是不明智的!
使用 VARCHAR(5) 和 VARCHAR(200) 存储 'hello' 的空间开销是一样的,那么使用更短的列有什么优势吗?
较大的列会使用更多的内存,因为 MySQL 通常会在内部分配固定大小的内存块来保存值。这对于使用内存临时表的排序操作来说尤其糟糕。在利用磁盘临时表进行文件排序时也同样糟糕。
最好的策略是只分配真正需要的空间。
CHAR
CHAR 是固定长度的:MySQL 总是为定义的字符串分配足够的空间。
CHAR 适合存储非常短的字符串,或者适用于所有值的长度都几乎相同的情况。
例如,对于用户密码的MD5 值,CHAR 是一个很好的选择,它们的长度总是相同的。
对于经常修改的数据,CHAR 也比 VARCHAR 更好,因为固定长度的行不容易出现碎片。
对于非常短的列,CHAR 也比 VARCHAR 更高效。
例如,设计为只保存 Y 和 N 的值的 CHAR(1) 在单字节字符集中只使用 1 字节,但 VARCHAR(1) 需要 2 字节,因为还有一个记录长度的额外字节。
当存储 CHAR 值时,MySQL 删除所有尾随空格。如果需要进行比较,值会用空格填充。
最后更新于