需要有关归档 MySQL (InnoDB) 表的最佳方法的建议

Question

问题：我有两张相当大的桌子。用于用户之间消息的“墙”表，2 GB，900 万行，“章”表，200 万行，18 GB。我想保持“墙”表的活动行数较小，同时我想减小章节表的大小。我犯了一个错误，一开始没有压缩文本数据，我想开始压缩档案中的数据。

对于“墙”表，我认为比某个墙 ID 更旧的所有内容都将被传输并压缩到“wall_archive”。任何想要查看较旧帖子的人都会获得一个“查看存档”链接，其中较旧的帖子查询使用存档表。然后我不时运行一个 cron 作业来执行此操作，并且存档的最后一个墙 ID 将存储在某处以供参考。我在这里走正确的方向吗？

我不太确定如何使“章节”表易于管理。也许归档更少，更需要对表（或两者）进行分区。但最好的方法是什么？我正在考虑将“故事”ID 分成赔率和偶数，并将章节分成两个表格，但我会再次遇到同样的问题。或者我可以存档在某个日期之前修改的故事。或者在某个故事ID之前。关于可扩展解决方案的任何建议？

最后，我应该如何压缩文本数据？我应该在第 9 级使用 PHP 的 gzcompress 函数将文本数据存储到 BLOB 列中，然后在检索时 gzuncompress 数据吗？还是应该使用 MySql 的 COMPRESS/UNCOMPRESS 函数？我倾向于使用 PHP，以防我将 Web 服务器与数据库服务器分开，在那里我可以让 PHP 执行压缩过程而不是更有价值的数据库服务器，但我想知道最佳实践是什么。

注意事项：我仍然需要能够轻松访问旧的“章节”数据。如果需要，“墙”数据可以放入较慢的存储中，但目前没有必要。

环境: 6 Core AMD Opteron, 16 GB RAM, 256 GB SSD for MySql, Percona Server 5.5, Apache, CentOS 6, PHP 5.3, innodb_file_per_table 已启用，数据库和网络服务器在同一台机器上运行，数据库总大小为 30 GB，所有表是 InnoDB

架构：

CREATE TABLE `wall` (
  `id_wall` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `id_author` int(10) unsigned NOT NULL 
     COMMENT 'wall''s owner',
  `id_user` int(10) unsigned NOT NULL DEFAULT '0'
     COMMENT 'user that wrote the comment',
  `comment` text NOT NULL,
  `created` datetime NOT NULL,
  PRIMARY KEY (`id_wall`),
  KEY `id_user` (`id_user`),
  KEY `id_author` (`id_author`)
) ENGINE=InnoDB
  DEFAULT CHARSET=utf8
  COMMENT='User profile wall'
  AUTO_INCREMENT=9710655 ;

CREATE TABLE IF NOT EXISTS `chapter` (
  `id_story` int(11) unsigned NOT NULL,
  `id_chapter` int(11) unsigned NOT NULL DEFAULT '0',
  `title` varchar(255) NOT NULL,
  `main_image` varchar(2047) DEFAULT NULL,
  `body` mediumtext,
  `created` datetime NOT NULL,
  `modified` datetime NOT NULL,
  `is_not_shown` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id_story`,`id_chapter`)
) ENGINE=InnoDB
  DEFAULT CHARSET=utf8
  ROW_FORMAT=DYNAMIC
  COMMENT='Story content by chapter';

ALTER TABLE `chapter`
  ADD CONSTRAINT `chapter_ibfk_1` 
    FOREIGN KEY (`id_story`) 
    REFERENCES `story` (`id_story`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE;

Answer 1

用于压缩...

在客户端进行；这将导致客户端和服务器之间的流量减少。（好吧，它们在同一台机器上，所以这不是什么大问题。）

使用PHP的gzcompress、gzuncomress；不用担心压缩级别。常规文本的压缩率约为 3:1。

是的，MEDIUMTEXT 需要是 MEDIUMBLOB。

不要“归档”旧数据；你还没有证明有必要这样做。缓存通常会负责使“最近”的章节更快。

查看 Facebook 和 Percona 的“在线更改”。

innodb_buffer_pool_size 应该约为可用内存的 70%。