何时应该使用MySQL压缩协议？

Question

我了解到MySQL可以压缩服务器和客户端之间的通信。

如果客户端和服务器都支持zlib压缩，并且客户端请求压缩，则会使用压缩。

(来自MySQL Forge Wiki)

最明显的优点和缺点是

• 优点：减少有效载荷大小
• 缺点：增加计算时间

那么，只要我能负担得起具备足够规格的服务器，就应该启用压缩协议吗？还有其他因素需要考虑吗？

- ento

---

网络速度和处理速度总是相互竞争。你的设置拥有更大的网络速度还是更大的处理速度？如果你拥有更大的网络速度，那么可以通过不压缩来节省处理时间。如果你拥有更大的处理速度，那么可以通过压缩来节省网络流量。 - Pacerier

Answer 1

性能优势主要取决于你发送的结果集的大小，以及数据库服务器和其客户端之间的网络带宽和延迟。

结果集越大、延迟越高或带宽越小，压缩就越有利。

你的最大服务水平受最小瓶颈的限制。因此，你需要分析你目前在网络和CPU资源方面处于什么水平。

最优化的数据库服务器百分之百地利用了它的CPU时间，否则你会浪费计算资源，因为处理器坐在那里没有做任何事情。当然，你不想让它超过100％，因此你的目标范围远低于100％。但我的观点是，如果你在达到CPU瓶颈之前还有很大的余地，并且结果集的大小相当大，网络也是一个因素，那就打开压缩功能。CPU周期是便宜的，尤其是未使用的周期（你需要支付电费和冷却费）。

如果你付费使用带宽，则为了获得更多的带宽，牺牲一些CPU使用率是很容易被接受的，即使你离带宽瓶颈很远，更快的速度和更高的服务水平也是有价值的。

不要忘记客户端也必须花费CPU周期来解压数据。这不是一个主要问题，但仍然是一个因素。总的来说，今天的CPU比今天的网络更快。

- Marcus Adams

Answer 2

虽然现在已经晚了，但我想分享一下：

• 大型结果集和压缩

事实证明，100 Mbit的链路（往返延迟时间为1.4毫秒）是不够快的...通过压缩，索引总时间从127秒缩短到87秒。这几乎是整个运行时间的1.5倍改进。MySQL查询时间的改进甚至更加显著。另一方面，1 Gbit的链路速度足够快；而启用压缩后，总运行时间要差1.2倍。

除非你的数据库和客户端在同一台机器上，在100 Mbits网络及以下，否则请启用压缩！

然而，你的最终决定也可能取决于 CPU 循环成本（压缩/解压缩）和带宽使用（更多数据传输）的平衡。

- jeremfg

---

非常棒的信息！但需要注意，这并不适用于所有情况。如果您的数据很容易压缩（每个查询中有大量重复数据）或者您的CPU性能更高，您可能需要进行自己的测试。 - Luke Rehmann

Answer 3

根据我的经验，大多数MySQL服务器都位于与Web服务器相同的服务器上，因此网络带宽不是问题。

我认为，除非您的数据库和应用程序/ Web服务器地理位置不同（即不在同一台服务器或网络上），否则启用压缩将几乎没有任何好处。

- Adam Hopkinson

---

大多数Web应用程序场景中都可以完全适用。但是对于许多客户端-服务器实现，数据库服务器在网络上附近的想法是不正确的。 - Elemental

Answer 4

从我的经验来看，如果您连接到完全不同的网络（甚至是国家）中驻留的外部MySQL服务器，则启用压缩特别有用。在这种情况下启用压缩所获得的好处取决于您传输的数据大小以及客户端和服务器之间的距离。像往常一样，您应该测试启用和禁用压缩的应用程序，然后决定哪种方式对您的情况最有益。对于这个问题没有绝对的答案。

如果您查询同一台机器上甚至是同一网络上的MySQL服务器，我认为启用压缩没有太大意义。

- reko_t