但是我不确定如何处理因为它们将位于同一台计算机（32GB RAM）上，所以提高了性能？
我正在使用MySQL，表将是MyISAM，大表将在id字段上具有索引，并且没有像full这样的进一步复杂性文本搜索等。
请同时说明表分区与数据库分区。
#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已经很小了。给定260百万行的分区，甚至很可能具有相同高度的多个BTREE。搜索密钥可能每次都会遍历所有BTREE根页面。只有一个人可以满足所需搜索范围的路径。
现在在此进行扩展。所有分区都存在于同一台计算机上。如果每个分区没有单独的磁盘，则磁盘I / O和主轴旋转将成为超出分区搜索性能的自动瓶颈。
在这种情况下，按数据库进行分区不会为您带来好处如果id是唯一要使用的搜索键，则不进行任何操作。
数据分区应用于对逻辑上和内聚性在同一类中的数据进行分组。只要将数据正确分组，搜索每个分区的性能就不必成为主要考虑因素。一旦完成了逻辑分区，就可以集中精力进行搜索了。如果仅按ID分隔数据，则可能永远无法访问多行数据进行读取或写入。现在，这应该是一个主要的考虑因素：找到最常访问的所有ID，并按此进行分区。所有访问次数较少的ID都应驻留在一个大的存档表中，该表仍可通过索引查找访问“一次蓝月亮”查询。
总体影响应该是至少具有两个分区：一个用于频繁访问的ID，另一个用于其余ID。如果经常访问的ID很大，则可以选择对其进行分区。
#2 楼
2亿行肯定在您可以从表分区中受益的范围内。根据您的应用程序，您可以打赌以下列出的一些好处：清除旧数据的便利性如果您需要清除（例如）六个月以上的记录，则可以按日期对表进行分区，然后换出较旧的分区。这比从表中删除数据要快得多，并且通常可以在实时系统上完成。在OP的情况下，这可能对系统维护很有帮助。
多个磁盘卷分区使您可以拆分数据，以跨多个磁盘卷分配磁盘流量以提高速度。有了现代的RAID控制器，这对于OP来说就不会成为问题。
更快的表和范围扫描确实，操作系统不应该做这种事情，但是数据仓库或类似的系统会做进行这种数量的查询。表扫描主要使用顺序磁盘流量，因此它们通常是处理查询的最有效方法，该查询返回表中多于百分之几的行。通过公用过滤器进行分区（通常基于时间或时间段）可以实现较大的如果可以针对分区键解析谓词，则要从此类查询中删除该表。它还允许将表拆分为多个卷，这对于大型数据集可以显着提高性能。通常，这对于操作系统而言不是问题。
出于OP的目的，分区不太可能为操作查询带来很多性能上的好处，但对系统管理可能有用。如果对报告大量数据的汇总有重大要求，则可以使用适当的分区方案来提供帮助。
#3 楼
如果所有索引都已分区，则分区允许按分区进行并发重组。如果不是这样，则分区仍会小得多，并使用较少的工作空间进行重组。而且，在内部，任何“好的” DBMS都可以与分区表并行执行操作。那可能不包括MySQL或MyISAM，等等。评论
MySQL不执行并行处理，即使涉及分区也是如此。 MySQL只索引一个分区；因此，UNIQUE和FOREIGN KEY在分区表中实际上并不可用。在MyISAM和InnoDB上进行分区-就此线程中讨论的内容而言没有区别。
–里克·詹姆斯（Rick James）
15年6月28日在18:21
评论
请说明将对除ID以外的表格执行哪种类型的索引搜索。它会提示您要进行的分区类型。只会是id。
“只有身份证”仍然没有告诉我们任何信息。 ID如何在所有ID的范围内分配？您主要是在查询较新的产品吗，它是真的分布吗？数据访问将主要是读取还是主要是写入？所有这些都是重要的问题，在为您提供具体帮助之前，我们需要对其进行解答。也就是说，下面的答案是非常有用的:)
这是我开始该主题五年后的感受。