当 ARCHIVE 不可用时，哪个 MySQL 存储引擎与 ARCHIVE 最相似？

Question

我有一个表，其中包含一个经常写入的事件日志，相比之下，它很少读取。我很想使用ARCHIVE引擎，因为它基本上就是为此而设计的。但是，我的托管服务提供商不提供此引擎。

唯一可用的（有用的）选项是 MyISAM、InnoDB 和 CSV。我敢肯定，我应该不使用CSV这个选项，让我们优惠的那一个。

我正在寻找的是提供最佳替代方案的引擎，请记住以下几点：

• 好的压缩会非常好。许多数据在行之间可能非常相似（就像日志消息的情况一样）
• 我不需要快速查找。索引并不是真正必要的。同样，我希望尽可能多地节省空间。
• 需要支持很多行。因此需要压缩和小足迹。
• 行确实有另一个表的外键，但没有必要保留这种关系。每个日志条目都有一个与之关联的名称，该名称存储在另一个不会更改的表中。

所以基于此，InnoDB 或 MyISAM 哪个更好。我知道这台服务器上安装的 MyISAM 引擎只支持 2^32 行。如果 InnoDB 对压缩有类似的支持并且支持更多的行，那会更好（但我不知道是不是这样）。

Answer 1

InnoDB 从 MySQL 5.1 开始支持压缩（使用 InnoDB 插件），或者在 MySQL 5.5 中原生支持。压缩级别实际上取决于您的表格内容，但我认为大小减少 75% 很常见。

读取和写入压缩表涉及更多 CPU。InnoDB 将支持您的外键以及任何索引。

对于您的问题，我会说这是一个相当不错的开箱即用的解决方案。

MyISAM 仅支持在只读模式下进行压缩。

或者您可能会找到一个完全 NoSQL 的解决方案来为您做好这项工作，因为您实际上并不需要索引。

我是一个关系极客，所以我会先去 InnoDB。只是：

ALTER TABLE my_table ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4;

KEY_BLOCK_SIZE可以是 1、4、8、16；较低的数字会给你更好的压缩。我的经验表明，4 提供了良好的压缩。1 很少有很大的改进，并且消耗更多的 CPU。