抓包前先确认是否真需抓包：若日志显示“the last packet sent successfully…0 milliseconds ago”，说明tcp连接未建立，应优先用telnet或nc验证网络层问题；仅当连接可建但sql执行后异常断连、超时或偶发失败时，才需tcpdump抓包分析rst、重传等现象。
抓包前先确认是否真要抓包
不是所有 Communications link failure 都需要抓包。如果错误日志里明确写着 The last packet sent successfully to the server was 0 milliseconds ago，说明连接根本没建立成功，问题大概率在 TCP 层（网络不通、端口拒接、防火墙拦截），这时候用 telnet 或 nc -zv host 3306 就能快速验证，抓包反而绕远路。
tcpdump 抓 MySQL 3306 流量的最小有效命令
真正需要抓包的场景通常是：连接能建上，但执行 SQL 后断连、超时或偶发失败——这时得看 TCP 包有没有被 RST、有没有重传、有没有 ACK 延迟。直接用下面这条命令，避免干扰：
tcpdump -i any port 3306 -w mysql.pcap -s 0
注意三点：
-
-i any：别指定网卡名，尤其在 Docker 或 Kubernetes 环境里，eth0可能不对； -
-s 0：必须加，否则 MySQL 协议头可能被截断，Wireshark 解析不了 handshake 或 error packet； - 不要加
host过滤：应用和 MySQL 可能在同一台机器，走的是 loopback，host会漏掉本地通信。
Wireshark 里快速定位异常的关键帧
打开 mysql.pcap 后，别从头翻。直接过滤：
tcp.flags.reset == 1 —— 找服务端主动 RST 的包，对应 MySQL kill 了空闲连接；
tcp.analysis.retransmission —— 找重传，说明网络丢包或延迟高；
mysql —— 显示所有 MySQL 协议层帧，重点看 Handshake Response 后有没有 OK_Packet，或者 Com_Query 后有没有响应。
如果看到客户端发了 Com_Query，但后面全是 TCP Retransmission，没有服务端回包，基本可锁定是 MySQL 进程卡死、OOM 被杀，或内核 conntrack 表满。
抓包时容易忽略的两个上下文
抓包本身不难，难在解读。必须同步记录两件事：
- 抓包期间的 MySQL 错误日志：查
/var/log/mysql/error.log里有没有Aborted connection或Got an error reading communication packets，这能和 RST 包时间对上； - 应用侧连接池状态：比如 Druid 的
DruidDataSource.getActiveCount()和getPoolingCount()，如果活跃连接数突增又暴跌，大概率是连接池在反复创建/销毁连接，而非网络问题。
抓包看到的只是链路现象，真正原因往往藏在 MySQL 的 wait_timeout 设置、连接池的 testWhileIdle 是否开启、甚至 JDK 的 NIO Selector bug 里——这些没法靠 Wireshark 直接看出。
