在 MySQL 5.7 中保留行大小 > 8126 的表有什么风险？

Question

我刚刚从 MySQL 5.6 升级到 5.7，并且意外地发现一个 WordPress 插件表包含一个荒谬的 438 个字段，并且超过了 8126 字节的行大小限制。

这是我在运行时收到的警告mysql_upgrade：

行大小太大 (> 8126)。将某些列更改为 TEXT 或 BLOB 或使用 ROW_FORMAT=DYNAMIC 或 ROW_FORMAT=COMPRESSED 可能会有所帮助。在当前行格式中，内联存储 768 字节的 BLOB 前缀。

不过，这只是一个警告，桌子还在那里。我无法创建具有相同结构的新表，但有趣的是，我可以保留旧表并使用它（至少，SELECT从它）。

我已经阅读了RolandoMySQLDBA和Bill Karwin对类似主题的回答，但没有任何解决方案可以帮助我：

我已经向插件开发人员报告了这个错误，并希望他们能尽快修复该表，但与此同时，我被这个非法表困住了。

所以问题是：

我从 MySQL 5.6 升级。我也尝试DYNAMIC和COMPRESSED格式，但没有运气。我计算了 integer + varchar 字段的大小，它们总共有 17,059 个字节，所以我没有机会以这种方式成功。

该插件名为Photo Gallery，故障表为wp_bwg_theme.

Answer 1

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=ON;
ALTER TABLE tbl ROW_FORMAT=DYNAMIC;  -- Or COMPRESSED

我认为这就是 5.6 所需要的。由于 Barracuda 和 file_per_table 在 5.7 中是默认值，因此大部分内容都消失了。但是，升级可能会保留表 Antelope 和/或不保留 file_per_table。

因此，我建议抛出这 3 个命令，看看它是否能永久“解决”您的问题。（是的，首先在某处保留某种备份。）

你提到了utf8；也许你也想要 utf8mb4 ？

ALTER TABLE tbl CONVERT TO utf8mb4;

（我现在不知道复制是否会成为问题。大概在上述更改之后，它在 5.7 Slave 上不会成为问题。）

编辑

但是...作为默认值（对于 5.7）并不意味着您在升级后获得了现有文件的这些值。

看看information_schema.INNODB_SYS_TABLES和file_format是row_format什么。space如果该值 > 0，则该列指示 file_per_table。

解决这个问题的一个彻底的方法是：改变InnoDB页面大小。默认值为 16KB，但也可以为 32KB。如果我没有记错的话，系统上的所有表都必须转换为新的页面大小，因此这是一项不小的任务，并且可能会产生其他影响。

/VARCHAR的处理DYNAMICCOMPRESSED

字符串何时存储在记录的主要部分中，而不是存储在其他块中？

“记录太大”：当行太长时，最长的列存储在页外存储中。也就是说，有时一列会完全不在页面上，有时会在页面上，具体取决于整行的构成。

VARCHAR和TEXT和对于orBLOB的处理方式相同。DYNAMICCOMPRESSED

该DYNAMIC格式基于以下思想：如果长数据值的一部分存储在页外，则将所有值存储在页外（“全部或无”）通常是最有效的。

COMPRESSED= DYNAMIC+ 压缩。KEY_BLOCK_SIZE控制有多少列数据存储在聚集索引中，以及有多少列数据放置在溢出页上。

在 MySQL 5.7 中保留行大小 &gt; 8126 的表有什么风险？