“Lost connection to MySQL server during query”不一定是网络问题，但丢包会直接触发断连；应先用mysqladmin ping、mtr和tcpdump验证网络质量，再结合net_read_timeout、net_write_timeout等参数及客户端驱动配置综合排查优化。
查网络丢包是否真导致连接中断
“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 秒而已。
