MySQL客户端从应用VM连接耗时超14秒的排查求助

看起来你碰到了个挺棘手的“连接慢但查数据快”的问题，先把你提到的关键信息再理一遍，确保没理解错：

• 你们用物理机搭了MySQL 4节点集群（2管理+2数据），每台配置都拉满：1TB内存+64核
• 你自己电脑连DB，秒连（耗时<1秒）
• 指定IP段的应用VM连DB，新连接要等14秒以上，但连接建立后查数据响应又正常（<1秒）
• 应用VM ping DB的平均延迟才1.3ms，基本排除基础网络延迟的问题

结合这些信息，给你几个优先级从高到低的排查方向，都是这类问题的常见元凶：

1. 先查MySQL的DNS反向解析（最可能的原因） #

MySQL默认会对客户端IP做反向DNS解析，用来验证客户端身份。如果应用VM的IP段在DNS服务器上没有对应的反向解析记录，MySQL在建立连接时会一直等解析超时，这直接导致连接慢。

• 临时测试方案：修改MySQL的配置文件（my.cnf或my.ini），加上skip-name-resolve参数，然后重启MySQL服务，再测应用VM的连接耗时。
• 如果测试后连接变快，那实锤是反向解析的锅。后续可以选两个方案：要么给应用VM的IP段在DNS上配置好反向解析；要么长期保留skip-name-resolve（注意：开这个参数后，MySQL权限表里不能用主机名授权，只能用IP，得确认你们的权限配置是基于IP的）。

2. 排查TCP连接层面的差异（ping不代表一切） #

ping用的是ICMP协议，和MySQL用的TCP协议走的网络路径处理逻辑可能不一样：

• 用traceroute <DB_IP>（Linux应用VM）或tracert <DB_IP>（Windows应用VM）查路由，看看中间有没有跳数延迟异常的节点。
• 测纯TCP握手的耗时：Linux下用time nc -zv <DB_IP> 3306，Windows PowerShell用Measure-Command { Test-NetConnection <DB_IP> -Port 3306 }，如果这个耗时就很高，那就是网络设备的问题——比如应用VM到DB的路径上有防火墙做了TCP连接的额外校验（比如IP信誉检查、流量清洗），这些操作不影响ping，但会拖慢TCP握手。
• 检查应用VM所在的安全组/防火墙：有没有对出站的3306端口做了特殊限制，比如速率限制、规则匹配等待？

3. 检查MySQL的连接和权限配置 #

• 看看MySQL的连接队列情况：执行show full processlist;，如果有大量处于Connect状态的进程，可能是连接队列满了，但你自己电脑能秒连，这个可能性相对低，但可以排除下。
• 检查应用VM用的连接账号：如果这个账号的权限配置是基于通配符主机名（比如user@%），MySQL在验证权限时可能会做额外的匹配检查，你可以专门给应用VM的IP段创建一个独立账号（比如app_user@192.168.x.%），测试连接耗时有没有变化。

4. 检查应用VM的本地配置 #

• 先测用IP连接DB：如果应用程序是用DB主机名连接的，换成IP试试，排除正向DNS解析慢的问题。
• 对比应用VM和你本地电脑的TCP参数：比如tcp_syn_retries、tcp_synack_retries这些参数，如果应用VM的重试次数配置过高，会导致TCP握手时的等待时间变长。

备注：内容来源于stack exchange，提问作者Basudev Rout