使用类似的MySQL表，但对一列的不同varchar大小保存DB大小，通过UNION查询

Question

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

当输入注释时，计算字符数，然后将条目保存到表中(通过if或switch php语句)，其中的varchar字符大小最小，注释与之匹配。

然后，就像使用UNION访问单个表一样，如下所示：

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

这个查询似乎没有问题-不同的注释字段大小似乎不会导致问题-但我想知道这个概念上是否有问题。这样做的原因是为了保存DB大小。我相信(假设1)，在varchar(30)列中有20个字符的注释字段占用的内存比varchar(500)列占用的内存要少。但是，我认为这种优化可能会内置到MySQL中，因此不需要我的低黑客攻击。也许它已经这样做了，所以我的假设1是完全不正确的？或者，可能会为varchar列设置一个会导致这种情况的设置？

我的问题瀑布：

1. MySQL是否已经在幕后进行了这样的优化，以至于一个具有一定数量字符的条目占用了相同的内存，而不考虑varchar设置，并且我不需要处理它？
2. 如果没有，是否有使其这样做的varchar设置？
3. 如果不是，这种类似表的概念，但对于varchar大小差，然后像一个表一样通过UNION访问，是否看起来是保存DB大小的有效且没有问题的方法？

Answer 1

varchar(30)和varchar(500)之间存储大小的差异(对于相同的字符串)是1字节。请参阅字符串类型存储要求

L表示给定字符串值的实际长度(以字节为单位)。 。。 VARCHAR(M), VARBINARY(M) ..如果列值需要0−255个字节，则为L+1个字节；如果值可能超过255个字节，则为L+2个字节

因此，不-不值得分割表和过度复杂您的代码。

我知道的唯一一种情况是，当您在MEMORY引擎中使用临时表时，这可能会产生很大的差异。然后，VARCHAR列将被扩展到它的最大大小(对于具有utf8mb4字符集的VARCHAR(500)来说是2000个字节)。

请参阅内存存储引擎

MEMORY表使用固定长度的行存储格式.可变长度类型(如VARCHAR )使用固定长度存储.