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

Question

关于无辜，最近有人告诉我：

超过768字节的varchar内容存储在补充的16K页中

这很有趣。如果每个varchar将是latin1，我相信它存储为每个字母1字节，那么一个varchar(500) (<768字节)是否会像varchar(1000) (>768字节)那样需要额外的i/o？(这个问题是要找出是否所有的varchars或仅仅是大varchars被分割成一个单独的页面)

每个varchar或行中所有varchars的768限制是加在一起的吗？(例如，这是否得到优化- varchar(300)、varchar(300)、varchar(300)：其中每个varchar列都低于768，但它们加在一起超过768个字符。

我感到困惑的是，768的限制是否涉及到每个单独的varchar或行中所有的varchars总计(如在问题中)。有什么澄清吗？

编辑:删除部分关于字符，因为发现他们的上限为255。

Answer 1

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

它还提到存储是length+data，这与您描述的不同。

我确实在MySQL压缩内件找到了一个分开的仓库

在以前版本的InnoDB中创建的表使用“Antelope”文件格式，它只支持ROW_FORMAT=REDUNDANT和ROW_FORMAT=COMPACT。在这些格式中，InnoDB将头768字节的BLOB、VARCHAR和TEXT列与主键一起存储在聚集索引记录中。768字节前缀后面跟着一个20字节指针，指向包含列值其余部分的溢出页。

对我来说，这意味着在确定该列是否需要溢出时，每个列都被单独考虑。

这似乎与较新版本的MySQL形成了对比，后者存储VARCHAR的方式似乎非常不同。更新版本中的VARCHAR的最大长度为65k字节，它似乎存储在记录本身(无溢出)中，这导致了约束，即所有列在一起不能超过65k字节。

查是很不一样的。它的最大长度是255，它存储在行本身中。因此，没有第(500)章:)

CHAR列的长度固定在创建表时声明的长度。长度可以是0到255之间的任意值。当存储CHAR值时，它们将以指定长度的空格填充.检索CHAR值时，除非启用PAD_CHAR_TO_FULL_LENGTH SQL模式，否则将移除尾随空格。