梭子魚和壓縮的好處
不久前，我一直在閱讀有關 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 上現在是預設文件格式。