mysql varchar innodb 页面大小限制 8100 字节

Question

关于innodb，最近有人告诉我:

"the varchar content beyond 768 bytes is stored in supplemental 16K pages"

这很有趣。如果每个 varchar 都是 latin1，我相信它存储为每个字母 1 个字节，那么单个 varchar(500)(<768 字节)是否需要额外的 i/o 作为 varchar(1000)(>768字节)会??(这道题是看是否所有的varchars或者只是大的varchars被拆分到一个单独的页面中)

是每个 varchar 的 768 限制还是行中所有 varchar 的限制加在一起？ (例如，这是否得到优化 - varchar(300)、varchar(300)、varchar(300):[其中每个单独的 varchar 列都低于 768，但它们加在一起超过 768 个字符]？

我对 768 限制是否与每个单独的 varchar 或行中的所有 varchars 总计有关(如问题中所示)感到困惑。任何澄清？

编辑:删除了有关 CHARS 的部分，因为发现它们的最大限制为 255。

Answer 1

documentation目前的 MySQL 并没有提到这个约束。它实际上给人的印象是 VARCHAR 存储在行本身中，因为一行中所有 VARCHAR 的长度总和不能超过 65k 字节。

里面还提到存储是length+data，跟你描述的不一样。

我确实在 MySQL compression internals 中找到了对拆分存储的提及:

Tables created in previous versions of InnoDB use the “Antelope” file format, which supports only ROW_FORMAT=REDUNDANT and ROW_FORMAT=COMPACT. In these formats, InnoDB stores the first 768 bytes of BLOB, VARCHAR and TEXT columns in the clustered index record along with the primary key. The 768-byte prefix is followed by a 20-byte pointer to the overflow pages that contain the rest of the column value.

对我来说，这表明在确定该列是否需要溢出时，应单独考虑每一列。

这似乎与 较新 版本的 MySQL 形成对比，后者似乎以完全不同的方式存储 VARCHAR。较新版本中的 VARCHAR 最大长度为 65k 字节，这似乎存储在记录本身中(没有溢出)，这导致约束所有列加起来不能超过 65k 字节。

CHAR 非常不同。它的最大长度为 255，并且存储在行本身中。所以没有 CHAR(500) :)

The length of a CHAR column is fixed to the length that you declare when you create the table. The length can be any value from 0 to 255. When CHAR values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed unless the PAD_CHAR_TO_FULL_LENGTH SQL mode is enabled.