垂直分区 MySQL 表

Posted 2023-04-18

【中文标题】垂直分区 MySQL 表

【英文标题】：Vertical Partition MySQL table

【发布时间】：2018-03-27 06:50:08

【问题描述】：

我正在审查一个案例，其中我有 200 多个列，主要是 varchar(100)。这些列来自多个外部数据源，如 CRM / Demographics 数据等。我无法将它们保存在一个列数不断增长的 mysql 表中。

一般查询情况可能包含来自一个或多个垂直分区的列。

垂直拆分它们是个好主意吗？并加入他们的查询？ 每个分区的大小（列数）应该是多少？提高性能。 最佳的 JOIN 匹配条件应该是什么？

MySQL 版本：5.7 存储引擎：InnoDB

【问题讨论】：

水平分区呢？

问题在于行大小限制。我认为水平分区将有助于大量行，而不是大量列。

好的，但是表格通常垂直而不是水平增长。

这些列必须有一些押韵或理由。来自一个数据源的一些列，来自另一个数据源的一些列，等等。为了真正回答您的问题，有必要更多地了解现有列及其来源。您只需要分析它们是什么以及它们的性质。

【参考方案1】：

如果列组是地址（街道、城市、州、国家、邮政编码），您可以/应该将多个地址移动到单个“位置”表中。 （其他逻辑分组也是如此。）

多列真的是“跨列展开的数组”吗？ eg, "foo1", foo2", "foo3", ...？这样的话，真正的应该不只是垂直分区，而是在另一个表中变成多行。

如果某些列确实是数字或日期，请使用适当的数据类型（在清理输入之后）。

你说“大多数是VARCHAR(100)”。制定合理的上限；这将有助于（某些）避免行大小限制。

某些列是否“稀疏”？也就是说，大多数行没有这些值的条目？然后收集到单个 JSON 列中。 （或几个 JSON 列，如果有明显的拆分。）如果您有旧版本的 MySQL/MariaDB（您没有），只需将 JSON 字符串放入 TEXT 列。

如果您仍然坚持垂直分区，那么列数和表数对JOIN 性能的影响很小。最好查看SELECTs 来决定在每个分区中放置哪些列——将所有搜索都放在一个表中（WHERE 子句命中多个表通常效率低下）。拥有一个通常不用的分区可能会让您避免使用JOINing。