我什么时候应该使用MySQL压缩协议？

Question

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

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

(来自MySQL Forge Wiki)

最明显的优点和缺点是

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

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

Answer 1

除了数据库服务器与其客户端之间的网络带宽和延迟之外,性能优势在很大程度上取决于您发送的结果集的大小.

结果集越大,延迟越大或带宽越少,您就越有可能看到压缩的好处.

您的最高服务水平仅限于最小的瓶颈.因此,您需要分析您目前在网络和CPU资源方面的位置.

最优化的数据库服务器在100%的时间内使用100%的CPU,否则你会因为处理器没有做任何事情而浪费计算资源.当然,您不希望它达到101%,因此您的目标范围远低于100%.然而,我的观点是,如果在达到CPU瓶颈之前有很大的空间,并且结果集的大小很大,而网络是一个因素,那么就打开压缩.CPU周期很便宜,特别是未使用的(你需要支付电费和冷却费).

如果您为带宽付费,那么交换CPU使用带宽很容易,即使您没有达到带宽瓶颈,更快的速度和更高的服务水平也是值得的.

不要忘记客户端还必须花费CPU周期来解压缩数据.不是一个重大问题,但仍然是一个因素.一般来说,今天的CPU比今天的网络更快.

Answer 2

我知道现在已经晚了,但我可能会分享这个:

• 大结果集与压缩

事实证明,100 Mbit链路(1.4 ms往返时间)不够 快......通过压缩,总索引时间从127秒减少到87秒.总运行时间几乎提高了1.5倍.MySQL查询时间的改进甚至更大.另一方面,1 Gbit链路足够快; 压缩后总运行时间缩短了1.2倍.

除非您的数据库和客户端在同一台计算机上,在100 Mbits网络上运行速度较慢,否则启用压缩!

但是,您的最终决定还可能取决于CPU周期成本(压缩/解压缩)和Bandwith使用(线路上的更多数据)之间的平衡.