Question

我们有一个名为posts_content的mysql表。

结构如下：

CREATE TABLE IF NOT EXISTS `posts_content` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `post_id` int(11) NOT NULL,
  `forum_id` int(11) NOT NULL,
  `content` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=79850 ;

问题是桌子变得非常庞大。许多千兆字节的数据（我们有一个爬行引擎）。

我们每天都会在表格中插入数据，但我们很少检索数据。现在随着桌子越来越大，它越来越难以处理桌面。

我们讨论了两种可能性

使用MySQL的分区功能使用forum_id对表进行分区（大约有50个forum_ids，因此大约有50个分区。请注意，即使是每个分区，如果这样做，最终也会再次增长到很多千兆字节的数据，甚至可能最终需要自己的驱动器
为每个forum_id创建单独的表，然后像这样分割数据。

我希望我已经清楚地解释了这个问题。我需要知道的是，从长远来看，以上哪两个是更好的解决方案。什么是adv。 dis adv。两种情况。

感谢你

Answer 1

不同之处在于，在第一种情况下，您要让MySQL进行分片，而在第二种情况下，您可以自己进行分片。 MySQL不会扫描任何不包含数据的分片，但如果您有查询WHERE forum_id IN(...)，则可能需要扫描多个分片。据我所知，在这种情况下，操作是同步的，例如， MySQL一次查询一个分区，您可能希望异步实现它。通常，如果您自己进行分区，则更灵活，但对于简单分区，基于forum_id，如果一次只查询1个forum_id，则MySQL分区正常。

我的建议是阅读有关分区的MySQL文档，尤其是restrictions and limitations部分，然后再决定。

Answer 2

这里有一个很好的答案：https://dba.stackexchange.com/a/24705/15243

基本上，让你的系统增长，当你熟悉分区时，当你的系统真的需要被“裁剪成碎片”时，可以通过分区来实现。

Answer 3

3x空间缩小（可能是加速）的快速解决方案是压缩content并将其放入MEDIUMBLOB。在客户端而不是服务器中进行压缩;这节省了带宽，并允许您在您拥有（或将拥有）的许多客户端服务器之间分配计算。

＆＃34;拆分＆＃34;将数据分散在多个服务器上。请参阅MariaDB和Spider。这允许尺寸增长和可能的性能缩放。如果你最终分片，forum_id可能是最好的。但是，假设没有一个论坛太大，无法放在一台服务器上。

＆＃34;分区＆＃34;拆分数据，但只在一台服务器内;您的用例似乎没有任何优势。通过forum_id进行分区不会提供任何性能。

删除FOREIGN KEYs;改为调试你的应用程序。

Mysql'Partitioning'与将数据拆分成不同的表

3 个答案: