8000万个地址。索引或分区？

我有一个约80万个地址（+电话）的表（innodb）。我将要更新另一个包含约750k条记录（电话和州）的表与匹配的地址。似乎最好的方法是按状态分组数据。在这种情况下索引或分区会更可取？我从来没有使用过这么大的数据集，所以我们将非常感谢正确方向的几个指针。另外，一旦我在手机/状态上匹配，我可能需要回圈并尝试仅基于手机重新匹配，以抢占任何电话/状态不匹配。8000万个地址。索引或分区？

来源

2014-10-07 Scott Hinton

无法提供索引或分区选项的建议，而不会更具体地查看您的查询试图优化看起来像。分区和索引都不会使* table *“更快” - 它们都用于更快地生成特定的查询。 – 2014-10-07 21:29:11

@BillKarwin：他的“电话/状态匹配”，因此在电话/状态上有一个索引对于执行此操作至关重要。 – 2014-10-07 21:32:16

对于MySQL（或任何现代的RDBMS），假设您正在适当的硬件上运行，那么8000万行不算大。

我建议应用适当的指数。在这种情况下，适当的索引应该是你想要通过电话/状态匹配的那一行。分区不应该是需要的。

在任何情况下，除非您有多个独立的存储分区（例如单独的物理硬盘驱动器等），否则分区将不会提供任何性能优势。

在附注中，请在开始操作之前了解数据质量。您可能需要清理数据。例如，一个表可能包含给定电话号码（234）555-1212，另一个表可能包含2345551212.

来源

2014-10-07 21:28:36

已经将电话消毒到只有10位数，所以我很好。你的回答确实有道理，并且符合我认为最好的方法。我最近才了解到分区。看起来合乎逻辑的是，按状态分解数据应该比索引更快。但是当我尝试使用中等数据集时，它似乎非常缓慢。但是就像你提到的那样，这是一个单一的高清。 – 2014-10-07 21:43:57

对于第二场比赛（仅手机），电话（唯一）索引是否具有任何用处？我试图远离索引独特的领域，因为它看起来有害。虽然在实践中，我看到查询使用它们的速度加快，但这并没有太大的意义。 – 2014-10-07 21:46:27

@ScottHinton：单个HD的分区速度会比较慢，因为您拥有所有的分区开销并没有任何好处。根据该值匹配行时，唯一索引非常有用。如果手机中没有索引（并且不是您的主键*不推荐*），您将对每个匹配的行执行表扫描。这通常比索引匹配慢几个数量级。 – 2014-10-07 21:50:15

8000万个地址。索引或分区？

回答

相关问题