mysql服务出现连接中断、查询响应延迟、事务提交失败等问题时，除了排查数据库本身的配置和性能问题，还需要重点检查网络连接是否存在丢包情况。网络层面的异常往往隐蔽性强，需要结合系统工具和mysql自身日志共同定位。
一、识别mysql网络连接丢包的典型现象
当mysql出现网络连接丢包时，通常会有以下可观测的表现：
- 应用端频繁出现
Communications link failure、Connection reset等连接异常报错 - mysql慢查询日志中突然出现大量耗时异常的查询，且查询逻辑本身无复杂操作
- 使用
show processlist命令查看连接状态时，存在大量处于Waiting for commit lock、Locked等异常状态的连接 - 数据库主从复制出现延迟，且从库IO线程频繁重连
二、基础排查步骤
1. 检查mysql服务与网络基础配置
首先确认mysql的网络监听配置是否正常，避免因为配置问题误判为丢包。可以通过以下命令查看mysql的监听端口和地址：
-- 查看mysql监听的端口和IP show variables like 'port'; show variables like 'bind_address';
同时检查服务器的防火墙规则，确认mysql监听端口没有被拦截：
# 查看防火墙规则，假设mysql端口为3306 iptables -L -n | grep 3306 # 如果是firewalld firewall-cmd --list-ports
2. 查看系统网络丢包统计
使用netstat命令查看网络接口层面的丢包情况，重点关注接收和发送的错误包数量：
# 查看所有网络接口的统计信息 netstat -i # 查看TCP协议层面的丢包重传情况 netstat -s | grep -i retrans
如果输出中RX-ERR（接收错误）、TX-ERR（发送错误）数值持续增长，或者segments retransmitted（重传段数）数值较高，说明存在网络丢包问题。
三、常用mysql网络诊断工具使用
1. tcpdump抓包分析
tcpdump是排查网络丢包最常用的工具，可以抓取mysql服务端口的网络包，分析是否存在丢包、重传等情况。以下是针对mysql端口的抓包示例：
# 抓取3306端口的所有网络包，保存到mysql_packets.pcap文件 tcpdump -i any port 3306 -w mysql_packets.pcap # 实时查看3306端口的TCP包，过滤重传包 tcpdump -i any port 3306 'tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-fin|tcp-rst) != 0'
抓包完成后可以使用wireshark打开pcap文件分析，重点关注TCP层的重传包、重复ACK包，这些通常是丢包的直接表现。如果是在pre代码块内需要展示链接，可以使用如下格式：
tcpdump使用教程
2. mysqladmin工具检测连接状态
mysql自带的mysqladmin工具可以定期检测mysql服务的连接响应情况，判断是否存在网络层面的连接异常：
# 每2秒检测一次mysql连接状态，共检测10次 mysqladmin -h 127.0.0.1 -P 3306 -u root -p ping --count=10 --sleep=2
如果输出中频繁出现mysqladmin: connect to server at '127.0.0.1' failed的报错，说明存在连接不稳定、丢包的问题。
3. 使用iperf测试网络带宽和丢包率
iperf可以测试两台服务器之间的网络质量，排除底层网络链路的问题。首先在mysql服务器上启动iperf服务端：
# 启动iperf服务端，监听5201端口 iperf -s
然后在应用服务器上启动iperf客户端，测试到mysql服务器的网络质量：
# 测试到mysql服务器的网络，持续30秒 iperf -c 192.168.0.1 -t 30
查看输出中的Loss字段，如果丢包率超过0.1%，就可能导致mysql连接出现异常。
四、丢包问题常见解决方案
根据排查结果，常见的解决方向包括：
- 如果是服务器网卡队列溢出导致的丢包，可以调整网卡缓冲区大小：
ethtool -G eth0 rx 4096 tx 4096 - 如果是网络链路带宽不足，需要升级网络带宽或者优化应用侧的数据库请求频率
- 如果是防火墙或者安全组规则误拦截，调整规则放行mysql端口的合法流量
- 如果是mysql连接数配置过高导致资源耗尽，调整
max_connections参数，避免连接过载
排查mysql网络丢包问题时，建议先排除应用侧和数据库本身的配置问题，再逐步深入网络链路层面，结合多个工具的结果交叉验证，才能快速定位根因。
mysqlnetwork_diagnosispacket_losstcpdump修改时间：2026-06-13 08:30:30