mysql - 使用类似的 MySQL 表，但一列的 varchar 大小不同，以节省数据库大小，通过 UNION 查询

Question

我正在创建 2 个类似的表，atesunion1 和 atestunion2，其列为:id、customer_id、product_id、comment、date。它们之间的唯一区别是 varchar 注释的长度。这种结构的“原因”如下。

输入注释时，会计算字符数，然后将条目保存到表中(通过 if 或 switch php 语句)，并使用注释适合的最小 varchar 字符大小。

然后，使用 UNION 像单个表一样访问它们，如下所示:

SELECT * FROM atestunion1 UNION SELECT * from atestunion2 ORDER BY date

这个查询似乎工作没有问题 - 不同的评论字段大小似乎不会导致问题 - 但我想知道这在概念上是否存在问题。这样做的原因是为了节省数据库大小。我相信(假设 1)varchar(30) 列中包含 20 个字符的注释字段占用的内存比 varchar(500) 列中的注释字段占用的内存更少。然而，我认为这种优化可能内置于 MySQL 中，因此不需要我的低级黑客。也许它已经这样做了，所以我的假设 1 根本不正确？或者，也许 varchar 列的某个设置会导致这种情况？

我的问题瀑布:

1. MySQL 是否已经在幕后进行了这样的优化，这样无论 varchar 设置如何，具有一定数量字符的条目都会占用相同的内存，这样我就不需要弄乱它？

2. 如果没有，是否有 varchar 的设置会导致它这样做？

3. 如果不是，这种相似表的概念，但由于 varchar 大小不同，然后通过 UNION 像单个表一样访问，看起来是一种有效且没有问题的节省数据库大小的方法吗？

Answer 1

varchar(30) 和 varchar(500)(对于同一字符串)存储大小的差异为一个字节。请参阅String Type Storage Requirements :

L represents the actual length in bytes of a given string value.

[..]

VARCHAR(M), VARBINARY(M) [..] L + 1 bytes if column values require 0 − 255 bytes, L + 2 bytes if values may require more than 255 bytes

所以不 - 不值得拆分表格并使代码过于复杂。

我所知道的唯一可能产生重大影响的情况是，当您将临时表与 MEMORY 引擎一起使用时。然后，VARCHAR 列将扩展到其最大大小(对于具有 utf8mb4 字符集的 VARCHAR(500) 为 2000 字节)。

参见The MEMORY Storage Engine :

MEMORY tables use a fixed-length row-storage format. Variable-length types such as VARCHAR are stored using a fixed length.