关于innodb，有人最近告诉我：
“varchar内容超过768字节 存储在补充的16K页“
中
这非常有趣。如果每个varchar将 latin1 ，我认为每个字母存储为1byte，则单个varchar（500）（<768字节）需要额外的i / o作为varchar（1000）（＆gt; ; 768字节）会?? （这个问题是要确定是否所有varchars或只是大的varchars被拆分成一个单独的页面）
每个varchar的768限制或行中的所有varchars是否加在一起？ （例如，这是否得到优化 - varchar（300），varchar（300），varchar（300）：[其中每个单独的varchar列低于768但是它们一起高于768个字符]？
我很困惑768限制是否与每个单独的varchar或行中的所有varchars相关（如问题所示）。有任何澄清吗？
编辑：删除了有关CHARS的部分，因为他们发现了最多255个限制
答案 0 :(得分：0)
当前MySQL的documentation没有提到这个约束。它实际上给人的印象是VARCHAR存储在行本身中，因为一行中所有VARCHAR的长度总和不能超过65k字节。
它还提到存储是长度+数据，这与您描述的不同。
我确实在MySQL compression internals中找到了分割存储：
在先前版本中创建的表 InnoDB使用“Antelope”文件格式， 仅支持 ROW_FORMAT =冗余和 ROW_FORMAT = COMPACT。在这些格式中， InnoDB存储了前768个字节 BLOB，VARCHAR和TEXT列中的 聚集索引记录与 首要的关键。 768字节的前缀是 接着是一个20字节的指针 包含其余内容的溢出页面 列值。
对我而言，这表明在确定该列是否需要溢出时，每个列都会被单独考虑。
这似乎与MySQL的较新的版本形成鲜明对比，它们似乎存储VARCHAR的方式完全不同。新版本中的VARCHAR最大长度为65k字节，似乎存储在记录中（无溢出），这导致约束所有列一起不超过65k字节。
CHAR非常不同。它的最大长度为255，并存储在行本身中。所以没有CHAR（500）：）
CHAR列的长度是固定的 到你宣布的时间长度 你创建表。长度可以 是0到255之间的任何值。当CHAR 值存储，它们是 右边有空格的 指定长度。当CHAR值是 检索到的尾随空格被删除 除非PAD_CHAR_TO_FULL_LENGTH SQL 模式已启用。