表分区有何帮助？

我很难掌握表分区的优缺点。我即将开始一个有8个表的项目，其中一个将是主要数据表，其中将包含180-2.6亿条记录。由于将对表进行正确的索引，因此我正在考虑将表记录限制为2000万，这样我就必须创建9-13个表。

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

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

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

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

如果将所有数据保留在一个表中（不进行分区），则使用键的搜索时间为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的高度。给定260百万行的分区，甚至很可能具有相同高度的多个BTREE。搜索密钥可能每次都会遍历所有BTREE根页面。只有一个能满足所需搜索范围的路径。

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

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

数据分区应用于对逻辑上和内聚性在同一类中的数据进行分组。只要将数据正确分组，搜索每个分区的性能就不必成为主要考虑因素。一旦完成了逻辑分区，就可以集中精力进行搜索了。如果仅按ID分隔数据，则可能永远无法访问多行数据进行读取或写入。现在，这应该成为主要考虑因素：找到所有最常访问的ID，并通过that进行分区。所有访问次数较少的ID都应驻留在一个大的归档表中，对于“一次蓝月亮”查询，索引查找仍可访问该表。

总体影响应至少有两个分区：一个分区用于频繁访问的ID，另一分区用于其余的ID。如果经常访问的ID很大，则可以选择对其进行分区。

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

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

• 多个磁盘卷通过分区，您可以拆分数据以在多个磁盘卷之间分配磁盘流量以提高速度。使用现代化的RAID控制器，这对于OP来说可能不是问题。

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

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

如果所有索引都已分区，则分区允许按分区进行并发重组。如果不是这样，则分区仍然要小得多，并使用较少的工作空间进行重组。而且，在内部，任何“好的” DBMS都可以与分区表并行执行操作。那可能不包括MySQL或MyISAM，等等。