MySQL远程连接慢大概率因未关闭skip-name-resolve，导致服务端对客户端IP进行反向DNS解析卡顿数秒；需在my.cnf[mysqld]段添加skip-name-resolve并重启，且授权表Host字段须改为IP或%。
MySQL 远程连接慢，大概率是 skip-name-resolve 没关
MySQL 默认会对每个新连接的客户端 IP 做反向 DNS 解析（查 hostname），如果 DNS 服务器响应慢、不可达，或本地 /etc/hosts 缺少对应条目，就会卡住几秒甚至几十秒。这不是网络延迟，而是 MySQL 主动在等 DNS 回复。
- 现象：执行
mysql -h x.x.x.x -u user -p后长时间无响应，但加-A或加--ssl-mode=DISABLED也没用——说明不是元数据加载或 SSL 的锅 - 验证方式：在 MySQL 服务端执行
SELECT USER(), CURRENT_USER();，如果返回的 host 是域名（如app@webserver.local）而不是 IP（如app@10.0.1.23），说明解析成功了；但如果连接卡顿且CURRENT_USER()返回的是 IP，大概率是解析失败后 fallback 导致的延迟 - 解决办法：在
my.cnf的[mysqld]段下加一行skip-name-resolve，然后重启 MySQL。注意：此后所有授权必须用 IP 或%，不能再写主机名（如GRANT ALL ON *.* TO 'user'@'web01'会失效）
wait_timeout 和 interactive_timeout 设置过低，导致连接被静默断开
这两个参数控制服务端“空闲多久就杀掉连接”，默认值通常是 28800 秒（8 小时），但很多 Docker 镜像或云数据库（如阿里云 RDS）会改成 300～600 秒。客户端连接池若没配好检测机制，就会拿到一个已被 MySQL 关闭的“假连接”。
- 典型报错：
Lost connection to MySQL server during query、MySQL server has gone away，但show processlist里看不到对应连接 - 检查当前值：
SELECT @@wait_timeout, @@interactive_timeout; - 临时调高（不重启）：
SET GLOBAL wait_timeout = 28800;（需 SUPER 权限）；生产环境建议写进配置文件并重启，避免动态设置被覆盖 - 配套动作：客户端连接池（如 HikariCP）必须设
connection-test-query=SELECT 1或启用validation-timeout，否则调高超时也没用
客户端用 -A 卡顿，其实是元数据预加载在拖慢连接
命令行客户端默认开启自动补全（auto-rehash），连接后立刻执行 SHOW DATABASES、SHOW TABLES 等 dozens 条查询来缓存结构。表越多、网络越差，卡得越明显——这不是连接慢，是“连上之后初始化慢”。
- 现象：
mysql -h x.x.x.x -u user -p进去要等半分钟，但加-A立刻进入；进去后敲USE db; SHOW TABLES;又卡 - 这不是 bug，是设计行为。除非你真需要 Tab 补全，否则远程连接一律加
-A（即--disable-auto-rehash） - 开发/运维脚本里务必显式带上
-A，比如mysql -h $HOST -u $USER -p$PASS -A -e "SELECT 1" - 应用代码里不用管这个——JDBC、PyMySQL 等驱动不走这套逻辑
中间网络设备 TCP 超时比 MySQL 还短
很多 NAT 网关、防火墙、负载均衡器（如 AWS ALB、腾讯云 CLB）默认 TCP 空闲超时是 300～600 秒，比 MySQL 的 wait_timeout 还短。连接在这类设备上先被掐断，MySQL 却不知道，仍认为连接活着。客户端发请求时才发现链路已断，表现为随机超时或重连失败。
- 验证方法：抓包看是否有
TCP RST出现在空闲连接上（用tcpdump -i any port 3306抓几分钟空闲后的包） - 解决路径有两条：要么调高中间设备的 idle timeout（如有权限），要么让客户端主动保活——例如 JDBC 加
?tcpKeepAlive=true，或连接池设keepalive-time（HikariCP 5.0+ 支持） - 别只盯着 MySQL 配置：云厂商控制台的安全组、NAT 网关、WAF 的连接超时项，往往比数据库本身更早动手
实际排查时，先跑 SELECT USER(), CURRENT_USER(); 和 SELECT @@wait_timeout;，再确认客户端是否用了 -A，最后查网络设备日志——三步之内，八成问题就定位清楚了。真正麻烦的不是参数调不对，而是多个超时层叠在一起，谁先断谁背锅。
