MySQL“手工”分区答案

【问题标题】：MySQL "hand-made" partitioningMySQL“手工”分区
【发布时间】：2020-07-08 06:31:38
【问题描述】：

我最近继承了一个遗留应用程序，包括一个 MySQL 数据库，它的核心是一个“表”，我们将其称为 Foo - 只是它不是一个实际的表，而是许多相同的表，名为 Foo01， Foo02... 到 Foo31。当记录的日期为NN 时，记录被插入到FooNN，此“分区逻辑”在应用程序层进行管理。

作为一个整体，Foo 以每天约 10 万行的稳定速度增长。总计数（~3M）和行数据表明每条记录在大约一个月后被删除/历史记录，所以大小不是一个大问题。随着时间的推移，插入以大致恒定的速率发生，不存在更新。 Foo 上的查询仅因用户（不是很多）进行手动搜索而发生，这些搜索可能会或可能不会被“分区”日期过滤，并且可能有也可能没有其他搜索参数。

对我来说，这看起来很像过去有人做了一个过早的优化，可能再加上一勺大胆的无知。但我不是任何专家，我只是想了解为什么有人会这样不顾一切。

这种方法有任何意义吗？即它是否比 MySQL 的内置分区有任何优势（使明显的缺点值得）？

【问题讨论】：

我想知道这个数据库是在分区存在之前构建的吗？
不要这么认为@P.Salmon，MySQL 已经进行了至少十年的分区，我称该应用程序为“遗留”，但它并没有那么旧。

标签： mysql sql database database-design partitioning

【解决方案1】：

您所描述的是典型的 SQL 反模式（换句话说，不是一个好的设计）。克服可能获得的微小性能提升有许多缺点，最突出的是：

需要多个表的查询编写起来很复杂
很难保证数据的完整性（表中没有主键）
结构维护存在问题（必须对所有表重复任何 DDL 操作）

如果您的数据不是太大，您可以将其直接存储在单个表中。

如果它有很多行，您可以使用 MySQL 具有本机分区。

如果有很多列并且不是所有的经常使用，您可以将结构垂直拆分并在另一个表中分隔经常使用的列。

【讨论】：

感谢您的回答@GMB，我知道缺点，我看不到优点，因此是我的问题。您提到了可能的（即使很小）性能提升，您介意对此进行扩展吗？它与 MySQL 的内置分区相比如何？
@willyjoker：从商业角度来看，可能没有优点。我想您可以通过重新设计来降低维护成本，但从业务角度来看，数据库可能已经足够好了。

【解决方案2】：

我会给出一些暂定的优点：

假设它是PARTITION BY RANGE(TO_DAYS(...))，这是唯一有用的模式，

用户编写的查询更简单。日期和日期范围非常相似，并且只针对一个表（用户查看）。
在更改为/从分区时，通常需要重新设计索引。这样做，您可以保持或提高性能。
删除“旧”数据（比单个表）更快且侵入性更小，因为它是DROP PARTITION。（好吧，foo## 也是快速且非侵入性的。）

从另一个角度来看，有句老话，“如果没坏，就不要修”。

关于分区的我的 cmets：http://mysql.rjweb.org/doc.php/partitionmaint

【讨论】：