问题：我有两张相当大的桌子。用于用户之间消息的“墙”表，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 …