不久前，我一直在阅读有关 MySQL 的文件格式 Antelope 和 Barracuda 的信息，我想知道我是否可以从 Barracuda 和 Compression 中受益。
我的服务器目前正在使用 Antelope，因为它是 MySQL 的默认设置。
由于我拥有的大型数据库，我曾多次遇到内存问题。我的数据库每天都在增加。
似乎压缩给一些人带来了好处，比如：
http ://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/
我知道内存和磁盘空间可能会更低，但我不确定我是否理解这一点（引自文章）：
“~5% CPU 负载根据顶部（从 80-100% 主要等待 I/O）
0.01按主键的平均查找时间（转换前 1-20 秒）"
我认为这两件事不会改善，因为如果数据被压缩，服务器必须解压缩才能再次获取原始数据，所以CPU 使用率会增加难道没有意义吗？
这对读/写密集型应用程序有好处吗？你会建议我改用梭子鱼和压缩吗？
你知道梭子鱼的任何问题吗？
以下问题的答案似乎指出了一些问题，但由于它是从 2011 年开始的，我想说它们现在已经修复：https ://serverfault.com/questions/258022/mysql-innodb-how-to-switch -到梭子鱼格式
关于“动态”，非压缩梭子鱼专用格式，与紧凑格式几乎没有什么变化，主要是关于如何存储 blob（以及任何非常动态的字段）。我从来没有遇到过紧凑与动态的问题，所以我可以安全地推荐梭子鱼的动态。请记住，梭子鱼还支持旧的冗余和紧凑行格式。
您提到的文章可能太旧了（5.1），正如 Percona 的首席执行官 Peter Z. 在评论中提到的那样，它可能有点误导。这并不意味着压缩不能获得巨大的收益，具体取决于工作负载。但是，我建议您在 >= 5.6 的版本上尝试它，因为 Facebook 和 Oracle 都对此进行了很多改进。
作为最近的参考资料，我建议您：
特别是，我喜欢 Facebook 材料，因为它们是第三方的（不需要议程），并且它们拥有世界上最大的 MySQL 部署之一。如您所见，他们将 SSD 技术与压缩相结合的设置非常成功。
会给你带来好处吗？这将取决于您的工作负载、工作集和设置（IOPS、内存）。根据您是 IO 限制、CPU 限制还是内存限制，压缩在某些情况下会产生负面影响，通过添加额外的 CPU、内存需求（压缩和未压缩的页面都存储在 InnoDB 缓冲池中）或生成太多压缩失败，增加延迟。它还取决于数据的类型：压缩对于大文本 blob 有很大帮助，但对于已经压缩的数据可能无用。
根据我的经验，在实践中，有些人认为压缩是性能的圣杯，并且对它非常满意，但在其他情况下，我们不得不恢复为未压缩的数据，因为没有获得任何收益。虽然非常繁重的写入工作量可能看起来像是一个糟糕的压缩环境，但如果在您的特定情况下，您不受 CPU 限制和内存限制，而是 iops 限制，它可能会很有帮助。
一般来说，很难预测结果，通常你应该设置一个测试环境来进行基准测试，然后找出为什么你会得到更好或更差的结果（这样你就可以使用不同的块大小等）。梭子鱼是完全安全的。压缩可能适合您，也可能不适合您。而且您始终可以尝试其他压缩方法，例如 blob 的客户端压缩（例如，如果您最终受 CPU 限制）或其他3rd 方引擎（如 RocksDB 和 TokuDB），其中压缩是重中之重，因为它专注于InnoDB 无法处理的更大数据集的性能。
简而言之：使用 Barracuda 的主要原因是 BLOB 处理、
innodb_large_prefix兼容性（大索引）和压缩。动态，在 MySQL 8.0 上现在是默认文件格式。