我了解到 MySQL 可以压缩服务器和客户端之间的通信。
如果客户端和 服务器支持 zlib 压缩，并且 客户端请求压缩。
（来自 MySQL Forge Wiki）
最明显的优点和缺点是
那么，只要我能负担得起具有足够规格的服务器，我就应该启用压缩协议吗？我还应该考虑其他因素吗？
性能优势在很大程度上取决于您发送的结果集的大小，以及数据库服务器与其客户端之间的网络带宽和延迟。
结果集越大、延迟越大或带宽越少，您就越有可能看到压缩的好处。
您的最高服务水平仅限于最小的瓶颈。因此，您需要分析当前的网络和 CPU 资源状况。
最优化的数据库服务器在 100% 的时间里充分利用其 CPU 的 100%，否则您会因为处理器坐在那里不执行任何操作而浪费计算资源。当然，您不希望它达到 101%，因此您的目标范围远低于 100%。然而，我的观点是，如果在达到 CPU 瓶颈之前有很大的空间，并且结果集很大，并且网络是一个因素，那么就打开压缩。 CPU 周期很便宜，尤其是未使用的周期（您需要支付电费和冷却费）。
如果您为带宽付费，那么用 CPU 使用率换取带宽是很合理的，即使您远未达到带宽瓶颈，更快的速度和更高水平的服务也是值得的。
不要忘记客户端还必须花费 CPU 周期来解压缩数据。虽然不是主要问题，但仍然是一个因素。一般来说，当今的 CPU 比当今的网络更快。
我想我可以分享这个：
事实证明，100 Mbit 链路（往返时间为 1.4 毫秒）不是 足够快...通过压缩，总索引时间减少到 87 秒 从 127 秒开始总运行时间几乎缩短了 1.5 倍。 MySQL 查询时间的改善甚至更大。另一方面 1 Gbit 链路 速度够快；总运行时间差 1.2 倍 压缩。
除非您的数据库和客户端位于同一台计算机上，在 100 Mbits 网络上且速度较慢，否则请启用压缩！
但是，您的最终决定可能还取决于 CPU 周期成本（压缩/解压缩）和带宽使用（线路上的更多数据）之间的平衡。
根据我的经验，大多数 mysql 服务器与 Web 服务器位于同一服务器上，因此网络带宽不是问题。
我想说，除非您的数据库和应用程序/Web 服务器在地理上分开（即不在同一服务器或网络上），否则启用压缩几乎没有什么好处。
根据我的经验，如果您连接到完全位于另一个网络（甚至国家）的外部 MySQL 服务器，它特别有用。在这种情况下启用压缩所带来的好处取决于您正在传输的数据的大小以及客户端和服务器之间的距离。与往常一样，您应该在使用和不使用压缩的情况下测试应用程序，然后做出最适合您情况的决定。这个问题没有绝对的答案。
如果您在同一台机器上，甚至在同一网络上查询 MySQL 服务器，我认为启用压缩没有多大意义。