MySQL网络延迟优化需从连接复用、数据压缩、地理就近部署和SQL效率四维度协同改进：启用连接池、开启协议压缩、同可用区部署、避免SELECT*及全表扫描。
MySQL网络延迟优化核心在于减少客户端与服务器之间的往返时间（RTT）、降低数据传输量、避免阻塞等待。重点不是调高某个参数，而是从连接方式、查询设计、网络配置和架构层面协同改进。
复用连接，避免频繁建连
每次TCP握手+SSL协商（如启用）会增加几十毫秒延迟，尤其在高并发短连接场景下影响显著。应用层应优先使用连接池（如HikariCP、Druid），设置合理最小空闲连接数和最大连接数，避免连接反复创建销毁。
- 确认MySQL服务端wait_timeout和interactive_timeout不宜过小（例如低于60秒），防止连接被意外中断
- 客户端开启autoReconnect=false（默认值），由连接池负责健康检测和重连，避免隐式重连引入不可控延迟
- 对简单查询，可考虑使用pipelining（如MySQL 8.0+支持多语句批量发送），减少多次往返
压缩传输数据，减少网络负载
大字段（如JSON、TEXT、BLOB）或宽表全量返回会显著拉长传输时间，尤其跨机房或公网访问时。
- 启用MySQL原生压缩协议：客户端连接时添加useCompression=true（JDBC）或启动--compress（mysql cli），服务端需开启protocol_compression_algorithms=zlib, zstd
- 只查所需字段，避免SELECT *；对大文本字段，用SUBSTRING()或应用层分段加载
- 结果集过大时，用LIMIT分页 + 游标（cursor-based pagination）替代OFFSET，避免服务端扫描冗余行
靠近部署，缩短物理链路
网络延迟主要由物理距离和中间节点决定，同城机房RTT通常1~2ms，跨城可能15~50ms，跨境常超100ms。
- 应用与MySQL尽量部署在同一可用区（AZ）内；跨AZ部署需确认内网带宽和延迟达标
- 避免应用直连公网IP，全部走VPC内网地址；云环境关闭安全组/ACL的非必要限制，防止包过滤引入抖动
- DNS解析慢也会拖累首次连接，建议在应用侧配置useServerPrepStmts=false并用IP直连，或本地hosts固化MySQL地址
优化查询执行，减少服务端等待
表面上是网络延迟，实际可能是查询执行慢导致客户端长时间等待响应，误判为“网络卡”。
- 开启slow_query_log，捕获执行时间>100ms的语句，结合EXPLAIN ANALYZE（MySQL 8.0.18+）定位瓶颈
- 确保WHERE条件字段有合适索引，避免全表扫描；注意索引失效场景（如函数操作、类型隐式转换）
- 写操作加锁时间长会阻塞后续读请求，考虑用READ COMMITTED隔离级别、拆分大事务、异步化非关键更新
不复杂但容易忽略。网络延迟不是单点问题，要从连接生命周期、数据体积、地理距离、SQL效率四个维度一起看。一次优化往往见效明显，尤其是把跨城直连改成同机房部署，延迟可能直接下降90%。
