我有一个88.9 GB的MySQL 5.0数据库坐在一个90GB的驱动器上。 该数据库包含许多用于我们（自定义）系统使用情况报告的MyISAM表。 这些数据是基于date的，基本上是Web服务器日志的聚合。
我想过把大表转换成MERGE存储引擎。 这个想法是，我可以将旧数据移动到不同的驱动器。 但是，我从来没有这样做过，对生产数据库的testing有点紧张。
而且，当然，我正在紧张的时间。 我必须尽快处理上个月的所有报告数据。 因此，安装更大的驱动器目前不是一种select。
有没有人有一些build议或经验分享减less这个数据库的大小？
有没有实际使用的任何指标？
好吧…这篇文章是OOOOLD ..但是..我认为如果是完整的，更好
当我必须将MySQL数据库移动到另一个分区时，我需要：
/etc/init.d/mysql stop rsync -avz /var/lib/mysql/ /mnt/anotherdisk/mysql/ mv /var/lib/mysql/ /var/lib/mysql_original/ ln -s /var/lib/mysql/ /mnt/anotherdisk/mysql/ /etc/init.d/mysql start
经过一天/一周/一个月/当IRememberOrCan，我做一个/ var / lib / mysql_original /的备份，然后删除该文件夹。
如果您已经在考虑将数据移动到更大的分区，您可以select性移动较大的表并将它们符号链接回数据库目录。 这有一些缺点，但是在文档中有logging。 这有一个容易退出的好处（假设你的表仍然适合旧的分区）。
MySQL中的符号链接
如果大部分数据都是日志聚合，则基本上有三个选项：
你准备重写应用程序吗？
OPTIMIZE TABLE将重build一个表来删除“洞”。 这可能会节省相当多的空间，或根本没有，取决于他们已经是多么优化。 然而这在大桌子上非常缓慢，并且使用了很多临时空间。
删除索引，将PACK_KEYS添加到表中，这些将减less索引的大小，但是这又涉及重build和使用临时空间。
你看过索引与数据的大小吗？
听起来你的服务器太满了，你真的无法做任何工作。
解决scheme：使用监控来确保在将来您的服务器永远不会满载，因为到了这个阶段，这是一个失败的原因。
在短期内，把整个地段转移到一个更大的箱子里。
我猜你已经试过了，但是有一个OPTIMIZE TABLE命令可以缩小它们，取决于它们的使用方式。
如果你不介意你的表变成只读的，你可以使用MyISAM PACK