mysql - MySQL“手工”分区
问题描述
我最近继承了一个遗留应用程序，包括一个 MySQL 数据库，它的核心是一个我们称之为“表”的“表” Foo——只是它不是一个实际的表，而是许多相同的表，命名为Foo01, Foo02... 到Foo31. FooNN当该记录的日期为 时插入记录NN，此“分区逻辑”在应用程序层进行管理。
总体而言，Foo以每天约 10 万行的稳定速度增长。总计数（~3M）和行数据表明每条记录在大约一个月后被删除/历史记录，所以大小不是一个大问题。随着时间的推移，插入以大致恒定的速率发生，不存在更新。查询的Foo发生只是因为用户（不是很多）进行手动搜索，可能会或可能不会被“分区”日期过滤，并且可能有也可能没有其他搜索参数。
对我来说，这看起来很像过去有人做了一个过早的优化，可能再加上一勺大胆的无知。但我不是任何专家，我只是想了解为什么有人会这样不顾一切。
这种方法有任何意义吗？即它是否比 MySQL 的内置分区有任何优势（使明显的缺点值得）？
解决方案
您所描述的是典型的 SQL 反模式（换句话说，不是一个好的设计）。克服可能获得的微小性能增益有许多缺点，最突出的是：
- 需要多个表的查询编写起来很复杂
- 强制数据完整性很难（表中没有主键）
- 结构维护存在问题（必须对所有表重复任何 DDL 操作）
如果您的数据不是太大，您可以将其直接存储在单个表中。
如果它有很多行，您可以使用 MySQL 具有本机分区。
如果有很多列并且不是所有的都经常使用，您可以将结构垂直拆分，并将常用列分隔到另一个表中。