mysql - 表分区与“手动”表分区

Question

我有以下选择：

我有一个巨大的表（9999999999999 行），我们称之为 tableHuge，我想将它拆分为多个表（以优化查询）。该表包含日期（一个月中的几天），并且大多数查询都是使用指定的月份作为 select 中的搜索键进行的。这导致我做出以下选择：

选择一个： 将表拆分为多个表，以一个月为他的尾巴（如lessHugeTable_01、lessHugeTable_02等）。然后我可以在我的应用程序中小心访问我需要的表。主要的缺点是失去加入的能力，在超过一个月的情况下（或加入工会......好吧......并发症）。

选择两个： 使用表分区。

由于我以前从未使用过分区（所以我没有比较知识），如果可能的话，我想要一些关于如何做到这一点的建议，利弊（除了明显的事情，比如“如果你的手动分区表坏了你只丢失了那些数据，而在表格部分你丢失了整个数据”）。

感谢您的宝贵时间。

Answer 1

这里的答案真的是“取决于”。

更具体地说，这取决于数据的性质、访问数据的对象以及访问数据的方式。

从听起来你可能最好使用按年和月分区的表。我在这里做出疯狂的假设，即您将需要不那么频繁/从不访问旧数据，因此能够将其归档以降低主表中的数据量（就像我说的“取决于”！）；

如果您的表是并且将始终由一个应用程序单独访问，您可以在其中构建逻辑来处理您的“尾部”命名约定，那么您可能希望采用多表路线。

以下是我对利弊叠加的看法：

多表优点

1. 如果只选择一个月的数据，则单个表会更小
2. 错误。实际上我只能想到一个

多表缺点

1. 难以查询/更新多月数据集
2. 如果您在二月表中获取一月的数据会怎样？ “但它永远不会发生！”。真的吗？真的吗？！
3. 如果多个应用程序需要访问这些表，那么它们都必须具备您的“尾部”命名约定逻辑，即 lessHugeTable_02 包含 2 月份的数据。

现在分区：

分区表的优点

1. 您让 MySQL 为您处理数据分片。因此，您的应用程序中不需要“本月 = 此表”逻辑
2. 1 月份的数据没有进入 2 月份表格的风险
3. 加入变得更加容易，因为您只有一个逻辑（如果不是物理）表
4. 如果您使用 MySQL 5.5 或更高版本，则可以truncate partitions。非常适合您可能想做的任何家务管理

分区表缺点

1. 您可能需要查询更大的数据集。如果您运行跨越多个分区的查询，则可能需要一段时间。 明智地选择您的分区键！
2. 可能更多，但我已经没有时间和疯狂的假设了！

PS 对某些点有很好的回答here