直接关闭MySQL的DNS反向解析最有效：在my.cnf的[mysqld]段添加skip_name_resolve=ON并重启；关闭后需将mysql.user表中域名授权（如'user'@'host.example.com'）全部改为IP或'%'，否则用户无法登录。
MySQL连接超时但ping正常，怀疑DNS解析慢怎么办？
直接关掉MySQL的DNS解析功能最有效。MySQL默认会把客户端IP反向解析成主机名（skip_name_resolve=OFF），一旦DNS服务器响应慢或不可达，每个新连接都会卡在gethostbyaddr()系统调用上，表现为“连接慢但ping通、telnet端口也通”。这不是网络问题，是MySQL自己在等DNS。
验证方法：在MySQL中执行SHOW PROCESSLIST;，看刚连上的线程状态是不是长期卡在Connecting to master或Checking host；或者用strace -p $(pgrep mysqld) -e trace=gethostbyaddr,gethostbyname抓系统调用，能看到阻塞点。
- 临时关闭：启动时加参数
--skip-name-resolve - 永久关闭：在
my.cnf的[mysqld]段下添加skip_name_resolve=ON，然后重启 - 注意：关闭后
GRANT语句里的'user'@'host'中的host只能写IP或%，不能写域名（否则权限不生效）
为什么skip_name_resolve=ON后部分用户突然无法登录？
因为已有GRANT记录里存的是域名（比如'app'@'web01.example.com'），而skip_name_resolve=ON后MySQL不再做反解，只认原始连接IP，匹配不上就拒绝登录。这不是bug，是行为变更的必然结果。
- 查问题账号：
SELECT user, host FROM mysql.user WHERE host NOT IN ('%', 'localhost', '127.0.0.1') AND host NOT REGEXP '^\d+\.\d+\.\d+\.\d+$'; - 修复方式：用IP重建授权，例如
GRANT SELECT ON db.* TO 'app'@'10.20.30.40'; FLUSH PRIVILEGES; - 如果必须保留域名白名单，就不能开
skip_name_resolve，得换用本地/etc/hosts加速反解，或优化DNS配置
不想改MySQL配置，还有没有更轻量的排查和缓解手段？
有，但只是临时定位和缓冲，不能替代skip_name_resolve。核心思路是区分“解析慢”和“连接慢”，并缩短等待时间。
- 用
mysql --host=127.0.0.1 -u... -p强制走IP，绕过主机名解析；对比--host=localhost是否明显变慢 - 检查
/etc/resolv.conf里DNS服务器是否响应慢：time dig -x <client_ip> @8.8.8.8</client_ip>，延迟超过300ms就要警惕 - 调整glibc的DNS超时（Linux）：在
/etc/resolv.conf里加options timeout:1 attempts:2，避免默认5秒×3次重试 -
tcpdump抓包确认：过滤port 53，看MySQL进程是否在连接建立后立即发了DNS查询
应用层直连IP后，为什么监控或日志里还显示主机名？
因为MySQL的processlist和慢日志中的host字段，是在连接建立**之后**才尝试反解的（即使skip_name_resolve=ON，某些版本仍会尝试）。所以你看到的日志里是空字符串、NULL或IP，取决于是否开了解析、以及解析是否成功——不是所有地方都同步受控。
真正影响性能的只有连接建立那一刻的反解动作。后续日志显示什么，不影响延迟，但会影响审计和权限判断逻辑。如果业务依赖PROCESSLIST里的主机名做路由或限流，就得在应用层自己传标识，别指望MySQL自动填对。
