php - mysql - 表分区与 "manual"表分区

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