Nun*_*uno 12 mysql innodb compression
不久前我一直在阅读有关 MySQL 的文件格式 Antelope 和 Barracuda 的信息，我想知道我是否可以从拥有 Barracuda 和 Compression 中受益。
我的服务器目前正在使用 Antelope，因为它是 MySQL 的默认设置。
由于我拥有的大型数据库，我多次遇到内存问题。我的数据库每天都在增加。
似乎压缩正在为一些人带来好处，例如：http :
//www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/
我知道内存和磁盘空间可能会更低，但我不确定我是否理解这一点（引自文章）：
“根据 top 约 5% CPU 负载（从 80-100% 主要等待 I/O）
0.01秒平均主键查找时间（转换前 1-20 秒）"
我认为这两件事不会改善，因为如果数据被压缩，服务器必须解压缩才能再次获得原始数据，那么CPU使用率会增加是否有意义？
这在读/写密集型应用程序中对您有好处吗？你会建议我改用 Barracuda 和 Compression 吗？
你知道梭子鱼的任何问题吗？
以下问题的答案似乎指出了一些问题，但由于它是 2011 年的，我想说它们现在已经修复：https : //serverfault.com/questions/258022/mysql-innodb-how-to-switch -到梭鱼格式
jyn*_*nus 15
关于“动态”，非压缩的梭子鱼专用格式，与紧凑相比几乎没有变化，主要是如何存储 blob（和任何非常动态的字段）。我从来没有遇到过紧凑型和动态型的问题，所以我可以安全地推荐梭子鱼的动态型。请记住，梭子鱼还支持旧的冗余和紧凑行格式。
您提到的文章可能太旧了 (5.1)，而且 Percona 的 CEO 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 上现在是默认文件格式。