如何通过检查网络丢包和调整net_read_timeout优化MySQL的Lost connection during query问题？

本文共计1080个文字，预计阅读时间需要5分钟。

数据库连接丢失，提示‘Lost connection to MySQL server during query’不一定完全是网络问题。可能是连接中断——比如中间有防火墙、云负载均衡或远程专线时延。先别急于修改配置，先检查网络是否畅通。

用 ping 只能看通不通，不能反映 MySQL 实际通信质量。真正该跑的是：

• mysqladmin -h your_host -u user -p ping —— 看连接层是否稳定（失败说明连接已断）
• mtr --report --tcp --port 3306 your_host —— 比 traceroute 更准，能持续统计每跳丢包率和延迟波动（注意：需安装 mtr，Linux 常见，macOS 可用 brew install mtr）
• 抓包确认：在客户端或服务器端运行 tcpdump -i any port 3306 -w mysql.pcap，复现报错后用 Wireshark 打开，搜 “RST” 或 “TCP Retransmission”，看到大量重传或 RST 包，基本锁定网络层异常

net_read_timeout 改多少才够用

net_read_timeout 控制的是“服务器等待客户端发来下一个请求包”的最大时间，不是查询执行时间。很多人误以为调大它就能撑住慢查询，其实它只影响客户端发完 SQL 后、服务器读取下一条命令前的空闲等待——对执行中查询本身没用。

但它对以下场景关键：

• 客户端使用长连接池，但应用逻辑里存在阻塞操作（如 Python 的 time.sleep()、Java 的 Thread.sleep()），之后才发下一条 SQL
• 客户端处理结果集耗时久（比如边 fetch 边写文件），导致服务器等不到下个请求
• 代理层（如 ProxySQL、HAProxy）设置了比 MySQL 更短的 read timeout，提前切断了连接

建议值：默认是 30 秒，生产环境可设为 120 或 300，但别盲目设成 86400（一天）。过大会掩盖真实问题，且占用服务器连接资源更久。改法：

SET GLOBAL net_read_timeout = 300;

或写进 my.cnf 的 [mysqld] 段：

net_read_timeout = 300

为什么调了 net_read_timeout 还报错

因为真正卡住查询的，往往不是 net_read_timeout，而是另外三个参数：

• wait_timeout：空闲连接超时（非交互式，如应用连接池里的连接）
• interactive_timeout：交互式连接超时（如 mysql 命令行）
• net_write_timeout：服务器向客户端写数据（比如返回百万行结果）超时

查当前值用：

SHOW VARIABLES LIKE '%timeout%';

重点盯 net_write_timeout —— 如果你查的是大结果集（SELECT * FROM huge_table），它才是最先触发 “during query” 断连的元凶。默认也是 30 秒，大导出或报表类查询建议同步调到 300。

客户端驱动也得配一致

服务端调了，客户端不配合照样断。常见坑：

• Python pymysql：连接时必须显式传 read_timeout=300, write_timeout=300，否则走默认 30 秒
• Java JDBC URL 加 &socketTimeout=300000（单位毫秒），不是 connectTimeout
• Node.js mysql2：选项里设 connectTimeout: 300000, waitForConnections: true，但要注意 socketTimeout 是每个 socket 操作的超时，不是全局
• mysqldump 导出大表：必须加 --net-read-timeout=300 --net-write-timeout=300 --max-allowed-packet=64M，三者缺一不可

最容易被忽略的是：这些客户端超时值，必须 ≥ 服务端对应参数，否则客户端先断，服务器还傻等。

网络和超时参数都是“保底手段”，真正稳的解法永远是：不让查询走到超时那步——建好索引、分页查、避免 SELECT *、拆大事务。否则再怎么调参，也只是把断连从第 30 秒拖到第 300 秒而已。