MySQL Partitioning / Sharding / Splitting - which way to go?我们拥有一个大约70 GB的InnoDB数据库，我们希望在未来2到3年内它将增长到数百GB。大约60％的数据属于单个表。目前，数据库运行良好，因为我们有一台具有64 GB RAM的服务器，因此几乎整个数据库都可以容纳到内存中，但是我们担心将来数据量会大大增加。目前，我们正在考虑一种拆分表的方法(尤其是占数据最大部分的表)，而我现在想知道，什么是最好的方法。 我目前知道的选项是
我们的应用程序基于J2EE和EJB 2.1构建(希望有一天我们会切换到EJB 3)。 你有什么建议？
编辑(2011-02-11)：
编辑(2014-06-04)： 此设置应该持续两年。然后，我们将不得不最终开始实施分片解决方案，或者仅购买具有1 TB RAM的服务器，这将使我们继续运行一段时间。 编辑(2016-01-18)： 此后，我们已将大表放在单独服务器上自己的数据库中。当前，该数据库的大小约为1.9 TB，另一个数据库(除"大"表以外的所有表)的大小为1.1 TB。 当前的硬件设置：
此设置的性能很好。 一旦该42 GB表不再适合内存，您肯定会开始遇到问题。实际上，一旦它不再适合内存，性能就会迅速下降。一种测试方法是将该表放在内存较少的另一台计算机上，并查看其性能如何。
这是不正确的。分区(通过MySQL 5.1中的功能或使用MERGE表的相同操作)可以提供显着的性能优势，即使这些表位于同一驱动器上也是如此。 举例来说，假设您正在使用日期范围在大表上运行SELECT查询。如果表是完整的，查询将被迫扫描整个表(以这种大小，即使使用索引也可能很慢)。分区的优点是查询将仅在绝对必要的分区上运行。如果每个分区的大小为1 GB，而您的查询只需要访问5个分区即可满足要求，那么合并的5 GB表对于MySQL来说要比42 GB的怪物版本容易得多。 您需要问自己的一件事是如何查询数据。如果您的查询有可能只需要访问某些数据块(即日期范围或ID范围)，则证明进行某种分区是有益的。 我听说MySQL 5.1分区仍然存在一些问题，特别是与MySQL选择正确的密钥有关。 MERGE表可以提供相同的功能，尽管它们需要更多的开销。 希望对您有帮助...祝您好运！ 如果您认为自己将受到IO /内存的限制，那么我认为分区将无济于事。像往常一样，首先进行基准测试将帮助您找出最佳方向。如果您没有配备64GB内存的备用服务器，则可以随时向供应商索取"演示单元"。 如果您不希望有1个查询汇总报告，则我倾向于分片。我假设您将分片整个数据库，而不仅仅是大表：最好将整个实体保持在一起。好吧，无论如何，如果您的模型能够很好地拆分。 这是一个在大型数据流的真实示例中MySql分区可以做什么的一个很好的例子： http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1 希望对您的情况有所帮助。 我会选择MariaDB InnoDB +分区(按键或按日期，具体取决于您的查询)。 我这样做了，现在我不再有任何数据库问题。 数秒之内即可将MySQL替换为MariaDB ...所有数据库文件保持不变。 前不久在Microsoft ArcReady事件中，我看到了有关可能对您有用的缩放模式的演示。您可以在线查看幻灯片。 您可能最终希望拆分大表。在考虑第二台服务器之前，您可能希望将其放在单独的硬盘上。使用MySQL进行操作是最方便的选择。如果有能力，那就去做。 但 实际上，一切都取决于数据库的使用方式。统计。
那就是大多数人告诉我的，所以我认为我最终将不得不服用该药... 大桌子做什么？
如果要拆分它，则有几种选择： 仅当您的数据可以轻松地分成多个块时，才可以按行拆分它。例如诸如Basecamp之类的东西有多个完全独立的帐户。您可以将50％的帐户保留在一个表中，并将50％的帐户保留在另一台计算机上的另一个表中。 按行拆分适用于行大小包含大文本字段或BLOBS的情况。如果您有一个包含(例如)用户图像和大量文本的表，则可以将图像植入完全不同的表中。 (在另一台机器上) 您在这里破坏了规范化，但是我认为这不会引起太多问题。 首先，拆分表并不重要，除非您还将某些表移到单独的物理卷上。 其次，不一定要移动最大物理尺寸的表。您可能有一个较小的表，可以进行更多活动，而大表保持相当恒定或仅附加数据。 无论您做什么，都不要自己实施。让数据库系统处理它。 |
