【发布时间】：2011-09-20 06:10:34
【问题描述】：
希望你们都做得很好。我们有一个名为“posts”的巨大 mysql 表。它有大约 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。
【问题讨论】：
-
你为什么首先使用 MyISAM？如果唯一的原因是全文索引，请考虑迁移到 InnoDB 并在 mysql（lucene/solr、sphinx）外部或自己处理全文。
-
@Darhazer - 感谢您的评论，尽管迁移到 InnoDB 的优势是什么。我并没有真正意识到这一点。 MyISAM 的缺点是什么？为什么要在mysql之外处理全文？
-
@Darhazer - 请查看我的问题中的更新部分
-
@Imran：70K 行并不是一张大表。有人会说它很小。一排有 300KB 闻起来很糟糕的数据库设计。我也很想看看其他桌子的设计。
-
MyISAM 使用表级锁，而 InnoDB 使用行级锁。如果有很多插入/更新，这会对性能产生巨大影响。此外，MyISAM 将在写入密集型应用程序中完全崩溃（它针对读取进行了优化）。我们正在使用 InnoDB 在 MySQL 中处理数百万条记录、数十 GB 表。 InnoDB 有许多 MyISAM 不支持的特性，比如事务。缺点是不支持全文索引。但是，将搜索移到数据库之外可以将数据库服务器从该操作中解放出来，这是一个通用的性能提示。