梭子鱼和压缩的好处

一段时间以前，我一直在阅读有关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梭子鱼格式

关于“动态”（Dynamic），一种非压缩的梭子鱼格式，与压缩格式相比几乎没有什么变化，主要是如何存储Blob（以及任何非常动态的字段）。我从未遇到过紧凑与动态的任何问题，因此我可以放心地推荐梭子鱼的动态。请记住，梭子鱼还支持旧的冗余行和紧凑行格式。

您提到的文章可能太旧了（5.1），正如Percona的首席执行官Peter Z.在评论中提到的那样，可能有些误导。这并不意味着根据工作负载，压缩不会获得巨大的收益。但是，我建议您在大于等于5.6的版本上尝试使用它，因为Facebook和Oracle都对此做了很多改进。

作为最新的参考资料，我建议您：

• 为Facebook规模的InnoDB压缩做好准备
• InnoDB压缩的现状和未来
• 评测InnoDB页面压缩性能

特别是，我喜欢Facebook资料，因为它们是第三方（不需要议程），并且它们是世界上最大的MySQL部署之一。如您所见，他们在结合SSD技术和压缩技术方面取得了非常成功的设置。

它对您有好处吗？这将取决于您的工作量，工作集和设置（IOPS，内存）。取决于您是受IO约束，CPU约束还是内存约束，在某些情况下，压缩可能产生负面影响，方法是添加额外的CPU，内存要求（压缩和未压缩的页面都存储在InnoDB缓冲池中）或生成太多的压缩失败，从而增加等待时间。它还取决于数据的类型：压缩对于较大的文本Blob会有很大帮助，但是对于已经压缩的数据可能没有用。

根据我的经验，实际上，对于某些人来说，压缩是性能的圣杯，并且对此感到非常满意，但是在其他情况下，由于没有获得任何收益，我们不得不恢复为未压缩的数据。尽管很繁重的写入工作似乎是一个糟糕的压缩环境，但如果在特定情况下，您不是cpu绑定和内存绑定的，而是iops绑定的，则可能会有所帮助。

通常，很难预测结果，通常应该设置一个测试环境进行基准测试，然后发现为什么会得到更好或更差的结果（这样您就可以使用不同的块大小，等等）。梭子鱼是完全安全的。压缩可能适合您，也可能不适合您。而且，您始终可以尝试使用其他压缩方法，例如客户端对Blob进行压缩（例如，如果最终受到CPU限制）或其他第三方引擎（例如RocksDB和TokuDB），因为压缩是重点，因此压缩是重中之重InnoDB无法处理的更大数据集的性能问题。

简而言之：使用梭子鱼的主要原因是BLOB处理，innodb_large_prefix兼容性（大索引）和压缩。动态，MySQL 8.0现在是默认文件格式。