在固定大小的字段上使用CHAR vs VARCHAR会对性能产生什么影响？

#1 楼

在

MySQL VARCHAR大小的性能影响之前，曾问过类似的问题。

这是我的答案的摘录

您必须意识到使用权衡因素CHAR与VARCHAR

通过CHAR字段，您分配的正是您所获得的。例如，无论您在字段中如何放置字符，CHAR（15）都会分配并存储15个字节。字符串操作简单明了，因为数据字段的大小是完全可以预测的。

使用VARCHAR字段，您会得到一个完全不同的故事。例如，VARCHAR（15）实际上动态分配最多16个字节，最多动态分配15个数据，以及至少分配1个额外字节来存储数据的长度。如果要存储的字符串'hello'将占用6个字节而不是5个字节，那么在所有情况下，字符串操作都必须始终执行某种形式的长度检查。

当您执行两个操作时，权衡更为明显事情：
1.存储数百万或数十亿行
2.索引CHAR或VARCHAR的列

TRADEOFF＃1
显然，VARCHAR的优势在于可变长度数据将产生较小的行，从而产生较小的物理文件。

TRADEOFF＃2
由于CHAR字段由于字段宽度固定而需要较少的字符串操作，因此针对CHAR字段的索引查找平均比VARCHAR字段快20％。就我而言，这不是任何猜测。 《 MySQL数据库设计和调优》这本书在MyISAM表上做了出色的工作来证明这一点。书中的示例执行了以下操作：

ALTER TABLE tblname ROW_FORMAT=FIXED;

此伪指令强制所有VARCHAR充当CHAR。我在2007年的上一份工作中做到了这一点，并使用了300GB的表，并将索引查找速度提高了20％，而没有进行任何其他更改。它像出版一样工作。但是，它的确产生了几乎两倍大的表，但这只是权衡了第一点。

您可以分析正在存储的数据，以查看MySQL对列定义的建议。只需对任何表运行以下命令：

SELECT * FROM tblname PROCEDURE ANALYSE();

这将遍历整个表，并根据其包含的数据，最小字段值，为每个列推荐列定义，最大字段值，依此类推。有时，您只需要在规划CHAR与VARCHAR时使用常识。这是一个很好的示例：

如果要存储IP地址，则该列的掩码最多为15个字符（xxx.xxx.xxx.xxx）。我会心跳地跳到CHAR(15)，因为IP地址的长度变化不会太大，而且字符串操作的复杂性由一个额外的字节控制。您仍然可以对这样的列执行PROCEDURE ANALYSE()。它甚至可能建议使用VARCHAR。在这种情况下，我的钱仍将放在CHAR上，而不是VARCHAR上。

CHAR与VARCHAR的问题只有通过适当的计划才能解决。强大的能力带来了巨大的责任（陈词滥调，但确实如此）。

UPDATE

当涉及到MD5时，在切换整个行格式时应在内部消除strlen的计算。无需更改字段定义。

如果MD5键是唯一存在的VARCHAR，我将使用它并将表行格式转换为固定格式。如果存在大量其他VARCHAR字段，它们也将受益。作为交换，桌子将扩大到其大小的两倍左右。但是，如果不进行其他调整，查询的速度应提高20％左右。

#2 楼

看起来您可以通过转换为char来为每个值节省1个字节或大约3％。如果仍然以十六进制存储MD5，则可能不值得-而是使用binary可以节省50％。

感谢Ovais（请参阅评论）指出，char(32)可以使用比如果使用的是多字节字符集，则为32个字节。

感谢Rick James指出您应该使用unhex函数将十六进制字符串转换为二进制：

create table foo(bar varbinary(100));
insert into foo(bar) values(md5('a')); 
insert into foo(bar) values(unhex(md5('a'))); 

select length(bar) from foo;

| length(bar) |
| ----------: |
|          32 |
|          16 |

db <>在这里拨弄

#3 楼

我认为这不值得改变。如果您浏览此处的文档，则应说明两者之间的区别。在您的使用场景中，除非您真的担心与行大小相关的额外开销，否则一个并不会真正提供任何明显的好处。
/doc/refman/5.0/zh-CN/char.html

还请注意上面链接到的文档的第一条评论...“如果整个记录都是固定大小的，则CHAR只会加快访问速度也就是说，如果使用任何可变大小的对象，也可以使它们全部变为可变大小。通过在还包含VARCHAR的表中使用CHAR不会加快速度。