启用压缩协议、批量操作、关闭自动提交、减少结果集拉取次数可显著降低高延迟网络下的MySQL交互开销。
用 mysql_real_connect() 启用压缩协议
MySQL 客户端与服务端之间传输大量数据时，网络带宽和延迟会显著拖慢查询响应。启用压缩协议能减少传输字节数，间接降低延迟敏感度。不是所有连接都默认开启，需显式传入 CLIENT_COMPRESS 标志。
- PHP 的
mysqli需在mysqli_real_connect()中设置MYSQLI_CLIENT_COMPRESS - Python 的
pymysql通过compress=True参数启用 - Java 的
mysql-connector-j对应配置项是useCompression=true - 注意：CPU 开销略有上升，但对高延迟（如跨城、跨云）链路收益明显
批量操作代替多次单行 INSERT / UPDATE
每次 SQL 执行都涉及至少一次往返（RTT），在 50ms 延迟的链路上，100 次单行插入就白白浪费 5 秒网络等待时间。合并为批量语句可大幅削减 RTT 次数。
- 用
INSERT INTO t VALUES (...), (...), (...)一次性插入多行 -
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE同样支持批量语法 - 避免在循环里反复调用
execute()；先拼好参数列表，再单次提交 - 注意
max_allowed_packet限制，批量过大可能触发Packets larger than max_allowed_packet错误
关闭自动提交 + 显式事务包裹写操作
默认每条 INSERT/UPDATE/DELETE 都是独立事务，意味着每次都要等服务端落盘并返回 ACK。在网络延迟高的场景下，这会把多个逻辑上可合并的 I/O 强制串行化。
- 执行
SET autocommit = 0后，用BEGIN/COMMIT包裹一组相关操作 - 尤其适用于 ETL、导入脚本、后台批处理等场景
- 不要在交互式应用中长期保持事务打开，否则可能阻塞 MVCC 清理或引发锁等待
- 确认业务允许一定范围内的原子性粒度——不是所有“多步更新”都必须在一个事务里
用 SELECT ... INTO OUTFILE 或客户端缓存减少结果集拉取次数
当应用需要遍历大结果集（比如导出百万行），逐行 fetch 会放大延迟影响：每 fetch 一行都可能触发一次网络请求（取决于驱动实现和缓冲策略）。更高效的方式是让服务端直接生成文件，或一次性拉取足够大的缓冲块。
-
SELECT ... INTO OUTFILE '/tmp/data.csv'让 MySQL 在服务端写文件，然后走其他通道（如 SFTP）取回 - 客户端驱动中调整
fetch_size（如 JDBC 的setFetchSize()）控制每次网络包携带的行数 - Python 的
cursor.fetchall()比fetchone()在高延迟下更省 RTT，前提是内存能承受 - 注意：
INTO OUTFILE要求 MySQL 有对应目录写权限，且不能覆盖已有文件
