MySQL - 每个表 450 列的好坏做法

Question

我有 450 多列的表。你能确认一下这样好吗，还是我需要拆分这张桌子？

如果是，MySQL 中每个表的列数将推荐什么值？

Answer 1

列数的技术限制取决于引擎。InnoDB在MySQL5.7中允许1017列，这1017列最多可以覆盖65535字节。记录存储在“页面”上。InnoDB允许页面大小配置为4、8、16、32、64Kb。您的记录必须适合一个页面，因此您不能将 5K 记录粘贴到 4K 页面上。

宽记录的问题在于，当数据库引擎检索记录时，它是以页为单位进行的。您可以在页面上获取很少的宽记录，因此检索性能会降低。数据库将结果提取到内存中，因此后续检索将在回退到存储之前查看数据是否保留在内存中。页面上有许多记录意味着页面的第一次物理检索更有可能加载到内存记录中，这些记录可以逻辑地（并且更快地）从内存中读取。

从设计角度来看，这取决于您的用例。在 OLTP 系统中，我会对 450 多个列感到不舒服。数据库不是一个愚蠢的存储。它可用于强制执行有关信息结构和不同数据实体之间关系的规则。这是您的武器库中极其强大的武器。

在支持某些分析系统的数据仓库中，450+ 听起来很多，但我已经看到一些广泛的非规范化表用于提供 OLAP 多维数据集技术。

如果我看到超过 450 个列的表，我还应该询问有关安全性的问题。当我授予对该表的访问权限时，我是否希望有权访问的每个人都可以访问所有 450 多个列？除了存储效率/性能标准化之外，安全设计也可以考虑在内。

考虑性能。在这 450 多个列中，哪些列大部分时间都被检索？如果定期只使用 32 列，您真的愿意承担检索 450 多个列的费用吗？

我给出的答案假设使用 InnoDB（默认）。