表分区有何帮助？

Question

我很难理解表分区的优缺点。我即将开始一个项目，该项目将有 8 个表，其中一个将是主数据表，将包含 180-260 百万条记录。因为它将是正确索引的表，所以我正在考虑将表记录限制为 2000 万，这样我将不得不创建 9-13 个表。

但我不太确定它将如何提高性能，因为它们将位于同一台机器上（32GB RAM）？

我正在使用 MySQL 并且表将是 MyISAM 并且大表将在 id 字段上有索引，并且没有进一步的复杂性，例如全文搜索等。

还请阐明表分区与数据库分区。

Answer 1

以下只是疯狂的咆哮和狂欢......

如果将所有数据保留在一个表中（不分区），则使用键的搜索时间将是 O(log n)。让我们以世界上最糟糕的索引，二叉树为例。每个树节点只有一个键。具有 268,435,455 (2^28 - 1) 个树节点的完美平衡二叉树的高度为 28。如果将此二叉树拆分为 16 棵独立的树，则会得到 16 棵二叉树，每棵树有 16,777,215 (2^24 - 1) 个高度为 24 的树节点。搜索路径减少了 4 个节点，高度减少了 14.2857%。如果搜索时间以微秒为单位，则搜索时间减少 14.2857% 几乎可以忽略不计。

现在在现实世界中，一个 BTREE 索引将具有多个键的树节点。每个 BTREE 搜索将在页面内执行二进制搜索，并可能下降到另一个页面。例如，如果每个 BTREE 页面包含 1024 个键，那么树高为 3 或 4 将是常态，确实是一个短的树高。

请注意，表的分区不会降低已经很小的 BTREE 的高度。给定 2.6 亿行的分区，甚至很有可能拥有多个高度相同的 BTREE。搜索密钥可能每次都经过所有根 BTREE 页面。只有一个将满足所需搜索范围的路径。

现在扩展一下。所有分区都存在于同一台机器上。如果每个分区没有单独的磁盘，则磁盘 I/O 和主轴旋转将成为分区搜索性能之外的自动瓶颈。

在这种情况下，如果 id 是唯一使用的搜索键，则按数据库分区也不会给您带来任何好处。

数据的分区应该用于对逻辑上和内聚性在同一类中的数据进行分组。只要数据正确分组，搜索每个分区的性能就不必是主要考虑因素。一旦实现了逻辑分区，就可以专注于搜索时间。如果您只是仅按 id 分隔数据，则可能永远无法访问多行数据以进行读取或写入。现在，这应该是一个主要考虑因素：找到所有最常访问的 id 并通过该 id 进行分区。所有不常访问的 id 都应该驻留在一个大的存档表中，该表仍然可以通过索引查找来访问“一次次”查询。

总体影响应该是至少有两个分区：一个分区用于频繁访问的 id，另一个分区用于其余 id。如果经常访问的 id 数量相当大，您可以选择对其进行分区。

Answer 2

2 亿行肯定在您可以从表分区中受益的范围内。根据您的应用程序，您可以押注下面列出的一些好处：

• 易于清除旧数据如果您需要清除超过（比如）6 个月前的记录，您可以按日期对表进行分区，然后换出旧分区。这比从表中删除数据要快得多，并且通常可以在实时系统上完成。在 OP 的情况下，这可能有助于系统维护。

• 多个磁盘卷分区允许您拆分数据以在多个磁盘卷之间分配磁盘流量以提高速度。使用现代 RAID 控制器，这对 OP 来说不太可能成为问题。

• 更快的表和范围扫描实际上，操作系统不应该做这种事情，但是数据仓库或类似的系统会做这种数量的查询。表扫描主要使用顺序磁盘流量，因此它们通常是处理返回表中超过百分之几行的查询的最有效方法。
  
  如果可以根据分区键解析谓词，则通过公共过滤器（通常基于时间或周期）进行分区允许从此类查询中消除大块表。它还允许将表拆分到多个卷上，这可以显着提高大型数据集的性能。通常，这对于操作系统来说不是问题。

出于 OP 的目的，分区不太可能为操作查询带来很大的性能优势，但它可能对系统管理有用。如果对报告大量数据的聚合有任何重要要求，那么适当的分区方案可能会有所帮助。