什麼時候應該使用MySQL壓縮協議？

Question

我瞭解到MySQL可以壓縮服務器和客戶端之間的通信。如果客戶端和服務器 支持zlib壓縮，以及 客戶端請求壓縮

使用壓縮。

（從MySQL Forge Wiki）

最明顯的優點和缺點都

• 優點：減少有效載荷大小
• 缺點：增加了計算時間

因此，被壓縮協議，我應該啓用，只要我可以負擔得起的服務器規格足夠？我應該考慮其他因素嗎？

Answer 1

除了數據庫服務器及其客戶端之間的網絡帶寬和延遲之外，性能優勢將很大程度上取決於您要發送的結果集的大小。

結果集越大，延遲越大或帶寬越少，您就越有可能看到壓縮的好處。

您的最高服務水平限於最小的瓶頸。因此，您需要分析您當前的網絡和CPU資源。

最優化的數據庫服務器在100％的時間內利用其100％的CPU，否則就會浪費計算資源，因爲處理器坐在那裏沒有做任何事情。當然，你不想要它在101％，所以你的目標範圍遠低於100％。然而，我的觀點是，如果在達到CPU瓶頸之前有足夠的空間，並且結果集很大，並且網絡是一個因素，那麼請打開壓縮。 CPU週期很便宜，尤其是未使用的（你付電費和散熱）。

如果您支付帶寬，交易帶寬的CPU使用情況很容易，即使您沒有接近帶寬瓶頸，那麼更快的速度和更高的服務水平也是值得的。

不要忘記，客戶端還必須花費CPU週期來解壓縮數據。不是一個主要問題，但仍然是一個因素。總的來說，今天的CPU比現在的網絡要快。

Answer 2

根據我的經驗，大多數mysql服務器與web服務器位於同一臺服務器上，因此網絡帶寬不是問題。

我想說，除非你的數據庫和應用程序/網絡服務器在地理上分開（即不在同一臺服務器或網絡上），否則在啓用壓縮方面幾乎沒有什麼好處。

Answer 3

根據我的經驗，如果您連接到駐留在完全另一個網絡（甚至是國家/地區）中的外部MySQL服務器，這將特別有用。您在這種情況下啓用壓縮的好處取決於您傳輸的數據大小以及客戶端與服務器之間的距離。與往常一樣，您應該測試應用程序是否進行壓縮，然後做出對您的情況最有利的決定。這個問題沒有絕對的答案。

如果您在同一臺機器上甚至同一個網絡上查詢MySQL服務器，我並沒有看到太多啓用壓縮的要點。

Answer 4

我知道這是晚了，但我以爲我會分享這個：

• Large result sets vs compression

事實證明，100兆位的鏈接（1.4 ms的往返時間）不是 足夠快...隨着壓縮，總索引時間從127秒減少到87秒 。總運行時間幾乎提高了1.5倍。 MySQL 查詢時間改進更大。另一方面，1 Gbit鏈接 足夠快;總壓縮時間是 壓縮的1.2倍。

除非您的數據庫和客戶端在同一臺機器上，在100 Mbits網絡上並且速度較慢，否則啓用壓縮！

但是，您的最終決定也可能取決於CPU週期（壓縮/解壓縮）成本與帶寬使用率（線路上的更多數據）之間的平衡。