【发布时间】：2011-03-23 01:12:43
【问题描述】：
varchar(1) 和char(1) 之间有性能差异吗？哪个 RDBMS 以不同的方式处理这两种数据类型和大小？
【问题讨论】：
标签： database-design data-modeling
【发布时间】：2011-03-23 01:12:43
【问题描述】：
这无关紧要，因为您在这两种情况下都使用 1 个字节。
但长话短说，varchar 是可变大小的，而 char 是固定大小的。大量使用时，这会影响存储空间并影响计算时间。
在性能方面，如果数据将是固定长度，请使用 char。如果您可以灵活处理不同长度的数据，请使用 varchar。
【讨论】：
-
*** 在这两种情况下都不是 1 个字节！ *** - 例如 - MYSQL v5.0 文档说 varchar(M) 的 varchar 存储要求需要“L + 1 个字节，如果列值需要 0 – 255 个字节”（其中 L 表示给定字符串值的实际长度（以字节为单位） )。所以你会为 CHAR(1) 使用 1 个字节，为 VARCHAR(1) 使用 2 个字节。在这种情况下，您将为此列使用 100% 以上的存储空间。根据使用情况，这可能或可能不是什么大问题。值得指出的区别是，以防万一。 （见dev.mysql.com/doc/refman/5.0/en/storage-requirements.html）
就甲骨文而言....
CHAR(2) 将始终使用两个字节/字符的存储空间。 VARCHAR2(2) 只能使用一个。所以一般情况是使用 VARCHAR2 而不是 CHAR。
在实践中，您不应该看到单字符列的性能差异。
由于 CHAR 没有任何好处，我总是使用 VARCHAR2。
【讨论】：
-
不过，varchar 仍然必须为字符串的长度存储至少一个字节，因此您永远不能少于 1 个字节。
在大多数情况下，差异可以忽略不计。将您以性能为导向的设计工作集中在能够产生真正影响的地方，例如表组合和索引设计。
它有助于将设计工作分为两层：逻辑设计和物理设计。
大多数以性能为导向的工作都在第二阶段，即物理设计。
在逻辑设计中，灵活性胜过性能。除非它没有。
【讨论】：
-
灵活性几乎永远不会胜过性能！我保证用户想要性能胜过灵活性，即使他们说他们想要灵活性。
阅读 MySQL 对 VARCHAR 和 CHAR 的描述后，我的理解是，如果您的数据始终具有相同的长度，那么 CHAR 可能会为您节省一个字节的数据，因为 VARCHAR 需要存储一个与实际数据，以记录数据的长度。但是，如果您的数据不是恒定长度并且您正在考虑空间问题，那么使用 VARCHAR 是有意义的，因为无论该空间中是否有任何内容，CHAR 都将始终为声明长度的每一位使用一个字节.
但最终，由于所涉及的数据量非常少，因此可能并没有那么大的区别。
这是我获得信息的地方：http://dev.mysql.com/doc/refman/5.0/en/char.html 如果您点击链接，请特别注意小图表，因为它提供了如何使用 VARCHAR 与 CHAR 处理数据的示例。
【讨论】：
在 MS SQL 中，VARCHAR(1) 使用 三个 字节的存储空间，CHAR(1) 使用 一个 字节的存储空间。
CHAR(1) 在处理和存储方面比VARCHAR(1) 更高效。
如果使用可变长度数据，VARCHAR 上的 盈亏平衡点 将大于 3 个字符。
如果使用固定长度，那么CHAR 总是比两个字节更有效。
【讨论】：
对于甲骨文
VARCHAR2(1) 和 CHAR(1) 在所有方面都是相同的。没有 在这种情况下使用 CHAR 类型的令人信服的理由，并避免任何 混淆，我“只是说不”，即使是 CHAR(1) 字段。
参考：https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2668391900346844476
【讨论】：
-
对驱动程序不适用。 Oracle .NET 驱动程序两者都不同。