处理庞大的MYSQL表

Question

希望你们都做得很好.我们有一个巨大的mysql表叫做'posts'.它有大约70,000条记录,大小已达到10GB左右.

我的老板说我必须做一些事情才能让我们轻松处理这个庞大的表格,因为如果那个表被破坏了,那么我们需要花很多时间来恢复表格.有时也很慢.

什么是可能的解决方案,以便处理此表变得更容易,如在所有方面.

该表的结构如下:

CREATE TABLE IF NOT EXISTS `posts` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `thread_id` int(11) unsigned NOT NULL,
  `content` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `first_post` mediumtext CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `publish` tinyint(1) NOT NULL,
  `deleted` tinyint(1) NOT NULL,
  `movedToWordPress` tinyint(1) NOT NULL,
  `image_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `video_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `video_image_src` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `thread_title` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `section_title` text CHARACTER SET utf8 COLLATE utf8_unicode_ci,
  `urlToPost` varchar(280) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `posts` int(11) DEFAULT NULL,
  `views` int(11) DEFAULT NULL,
  `forum_name` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `subject` varchar(150) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  `visited` int(11) DEFAULT '0',
  `replicated` tinyint(4) DEFAULT '0',
  `createdOn` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `urlToPost` (`urlToPost`,`forum_name`),
  KEY `thread_id` (`thread_id`),
  KEY `publish` (`publish`),
  KEY `createdOn` (`createdOn`),
  KEY `movedToWordPress` (`movedToWordPress`),
  KEY `deleted` (`deleted`),
  KEY `forum_name` (`forum_name`),
  KEY `subject` (`subject`),
  FULLTEXT KEY `first_post` (`first_post`,`thread_title`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=78773 ;

感谢您.

更新

注意:虽然我对回复很满意,但几乎所有答案都是关于优化当前数据库而不是如何一般处理大表.虽然我可以根据我得到的回复来优化数据库,但它确实没有回答有关处理大型数据库的问题.现在我正在谈论70,000条记录,但在接下来的几个月内,如果不是几周,我们将会增长.每条记录的大小约为300kb.

Answer 1

我的回答也是前两条评论的补充.

你已经将你桌子的一半编入索引了.但是如果你看一些索引(publish,deleted,movedToWordPress),你会注意到它们是1或0,所以它们的选择性很低(行数除以该列的不同值的数量).这些指数是浪费空间.

有些事情也毫无意义. tinyint(4) - 这实际上并不是一个4位整数.数字有显示长度.tinyint是1个字节,因此它有256个可能的值.我假设那里出了问题.

还有10个演出,只有75k的唱片？你是如何衡量尺寸的？另外,你得到的硬件是什么？

针对您更新的问题进行修改:

有许多方法可以扩展数据库.我会链接一个SO问题/答案,这样你就可以了解你能做什么:这里是.你可能做的另一件事是获得更好的硬件.通常,数据库在大小增加时速度慢的原因是HDD子系统和剩余的可用内存与数据集一起使用.你拥有的RAM越多 - 它就越快.

您可以做的另一件事是将表拆分为两个,使得一个表保存文本数据,另一个表保存与系统执行特定搜索或匹配所需的数据相关的数据(您可以在其中放置整数字段).使用InnoDB,如果两个表通过某种指向主键的外键连接,您将获得巨大的性能提升.由于InnoDB使主键查找速度很快 - 您可以使用数据集开启几种新的可能性.如果您的数据变得越来越大,您可以获得足够的RAM,而InnoDB将尝试在RAM中缓冲数据集.有一个名为HandlerSocket的有趣的东西,它对具有足够RAM并使用InnoDB的服务器做了一些巧妙的魔术.

最后,它真正归结为您需要做什么以及如何做到这一点.既然你没有提到这一点,那么很难估计你应该做些什么.我优化的第一步肯定是调整MySQL实例并支持那个大表.