当客户端向MySQL发起连接时，TCP三次握手和身份认证通常能在几十毫秒内完成，但有些环境的登录过程却会莫名卡住几秒甚至更久。此时如果SQL语句执行很快，仅连接阶段缓慢，最先要检查的就是MySQL是否在连接建立后对客户端IP执行了反向DNS解析。反向解析原本用于将IP转换为主机名，便于权限匹配和错误日志可读性，但如果DNS服务器不可达、配置错误或网络延迟高，这个解析动作会直接拖慢整个连接过程。
MySQL连接建立时的DNS解析机制
MySQL在默认配置下，每当有新的客户端连接到来，会尝试调用系统解析器对客户端的IP地址做反向DNS查询，也就是通过IP查找对应的主机名。这一步并不是毫无意义：MySQL的权限表mysql.user中可以针对主机名授权，例如允许appserver.internal访问，而不是只允许IP访问。如果账号授权使用了主机名，MySQL必须先把来源IP解析成主机名，再与权限表中的Host字段进行匹配。
反向DNS查询通常依赖操作系统配置的DNS服务器，例如/etc/resolv.conf中指定的nameserver。如果该DNS服务器反应迟钝、存在丢包，或者客户端IP本来就没有PTR记录，解析过程可能需要等待超时才会返回。这个等待时间与MySQL配置无关，而与操作系统的解析器超时策略有关，常见表现就是连接命令卡住几秒后又能正常登录。对于大量短连接应用，每次连接都触发一次DNS查询，累积的延迟会非常可观。
还需要区分的概念是：正向解析是把域名变成IP，反向解析是把IP变成域名。MySQL连接阶段主要涉及反向解析，因为客户端只暴露了来源IP。正向DNS解析则可能出现在客户端使用域名连接MySQL时，但那一部分通常由客户端自身完成，不会卡在MySQL服务端。因此排查服务端连接慢时，关注点应集中在skip_name_resolve以及系统DNS配置上。
如何确认DNS解析导致连接缓慢
定位问题不能只凭感觉，可以先从MySQL参数状态入手。登录MySQL后执行以下语句，查看skip_name_resolve当前的取值：
SHOW VARIABLES LIKE 'skip_name_resolve';
如果返回OFF，说明MySQL当前未跳过名称解析，连接创建时会执行反向DNS查询。这个参数是只读的，不能在会话中动态修改，想要改变它必须调整配置文件并重启服务。另一个值得查看的是host_cache相关参数，MySQL会缓存解析结果，但如果缓存未命中或过期，仍然会发起新的DNS请求。
其次可以直接在操作系统层面测试反向DNS解析的耗时。例如在Linux服务器上，使用getent hosts 192.168.1.50或nslookup 192.168.1.50观察返回速度和结果。如果这些命令本身就要等待数秒，或者返回NXDOMAIN，就说明DNS解析链路有问题。这时即使MySQL本身配置正常，连接也会被拖慢。
time getent hosts 192.168.1.50 time nslookup 192.168.1.50
此外，还可以通过开启MySQL的错误日志或通用查询日志辅助判断，但更直接的方法是进行连接耗时对比。可以准备两个用户，一个Host为具体IP地址，另一个Host为主机名。从同一客户端发起连接，如果主机名用户明显变慢，就进一步说明解析步骤贡献了延迟。
配置skip_name_resolve与验证效果
当确认反向DNS解析是主要瓶颈后，最简单的优化方法是在MySQL配置中启用skip_name_resolve。这会让MySQL在连接处理阶段跳过IP到主机名的反向解析，把所有客户端来源都视为IP地址来处理。配置文件通常为/etc/my.cnf或/etc/mysql/my.cnf，在[mysqld]段落中加入：
[mysqld] skip_name_resolve=ON
保存后需要重启MySQL服务，例如在基于systemd的系统上执行：
systemctl restart mysql
重启后再执行SHOW VARIABLES LIKE 'skip_name_resolve';，确认值已经变为ON。为了验证连接速度是否改善，可以使用time命令测量建立连接并执行简单查询的总耗时：
time mysql -h 192.168.1.100 -u app_user -pYourPassword -e "SELECT 1"
测试时建议执行多次取平均，避免偶然波动。如果连接时间从数秒下降到几十毫秒，说明优化方向正确。需要注意的是，skip_name_resolve开启后，所有基于主机名的授权匹配会失效，必须检查业务账号的Host字段是否填写了主机名而非IP。
关闭DNS解析后的权限与安全注意事项
跳过名称解析并不是无代价的。MySQL权限表mysql.user、mysql.db、mysql.tables_priv等表中，Host字段如果写的是主机名，开启skip_name_resolve后这些授权规则将无法匹配，可能导致原本可用的账号被拒绝登录。例如某账号的Host为appserver.internal，关闭解析后MySQL只会拿客户端IP去比较，结果不匹配，就会报访问被拒绝。
因此在启用该参数之前，需要先审查现有账号的Host值。可以执行以下SQL找出所有非IP、非localhost的主机名授权：
SELECT user, host FROM mysql.user
WHERE host NOT IN ('localhost', '127.0.0.1', '::1')
AND host NOT REGEXP '^[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+$';
对于使用主机名授权的账号，应将其调整为具体IP、网段或使用通配符的IP形式，例如从appserver.internal改为192.168.1.50或192.168.1.%。修改完成后执行FLUSH PRIVILEGES;让授权生效。同时还要关注应用连接串中是否使用域名访问数据库，如果使用了域名，该域名解析在客户端完成，不受服务端skip_name_resolve影响，因此无需改动应用。
安全方面，关闭DNS解析可以降低MySQL服务端对DNS服务器的依赖，也减少DNS欺骗或解析结果不一致带来的授权风险。但如果有业务依赖主机名进行细粒度访问控制，则需要通过防火墙或网络白名单等其他方式实现等效控制。对于云环境或容器环境，DNS解析通常相对稳定，但如果出现间歇性连接变慢，同样可以优先尝试开启该参数观察变化。
最后强调，连接慢还可能由其他因素造成：如back_log队列过小、线程创建开销过大、SSL握手耗时、DNS缓存未命中、防火墙限制等。建议结合SHOW GLOBAL STATUS LIKE 'Threads_created'和SHOW VARIABLES LIKE 'max_connections'综合判断。如果只想解决连接阶段响应时间过长，先检查DNS解析并评估skip_name_resolve，通常能获得明显改善。
MySQL连接慢DNS反解析skip_name_resolve修改时间：2026-08-22 07:41:44