加skip-name-resolve可解决MySQL启动卡在“Resolving host…”问题，但必须置于[mysqld]段、完整重启服务，并将授权Host改为IP或%，否则因权限不匹配导致连接失败。
MySQL启动卡在“Resolving host…”是反向DNS解析阻塞
Linux下MySQL启动慢、日志里反复出现Resolving host...或gethostbyaddr()调用超时，基本可断定是服务端对本地IP（如127.0.0.1）或监听网卡IP做反向DNS解析失败。这不是配置错、磁盘慢或资源不足，而是mysqld进程在初始化网络监听时，对每个绑定地址执行PTR查询——若DNS服务器不可达或内网没配反向解析记录，它会等满默认30秒才放弃。
skip-name-resolve必须写在[mysqld]段并完整重启
只改配置文件不生效是高频错误。关键点有三个：
-
skip-name-resolve必须放在[mysqld]节内，写在[client]、[mysql]或文件开头无效 - Ubuntu/Debian用户要确认最终加载路径：运行
mysqld --verbose --help | grep "Default options"，看是否被!includedir /etc/mysql/conf.d/下的其他文件覆盖 -
systemctl reload mysql不触发重载该参数，必须systemctl restart mysql（或mysqld）
验证是否生效：连接后执行SHOW VARIABLES LIKE 'skip_name_resolve';，返回ON才算成功。
开了skip-name-resolve后权限全失效的真正原因
这不是bug，是设计行为：启用后，MySQL彻底跳过所有DNS解析，user@host中的host字段只能按字面值匹配IP或通配符%，不再接受localhost、web01.example.com这类域名。
- 典型现象：
GRANT ... TO 'root'@'localhost'账号，用mysql -h 127.0.0.1登录直接报Access denied - 查隐患账号：
SELECT User, Host FROM mysql.user WHERE Host NOT IN ('%', '127.0.0.1', '::1', 'localhost'); - 更新方式：
UPDATE mysql.user SET Host = '10.0.2.5' WHERE User = 'app' AND Host = 'web01.example.com';，然后FLUSH PRIVILEGES;
Kubernetes等动态IP环境慎用——Pod IP每次重启都变，硬编码IP不可持续，此时应评估是否真能关反查。
别只盯着启动慢，先确认是不是它导致的
用两个低成本方法快速定位，避免白改配置：
- 临时停DNS服务：
sudo systemctl stop systemd-resolved，再systemctl restart mysql，如果启动变快，就是它 - 换IPv6回环测试：
mysql -h ::1 -u root -p，如果IPv4卡顿但IPv6立即响应，说明IPv4的gethostbyaddr()在阻塞 - 查
information_schema.PROCESSLIST：如果HOST列全是IP（如10.0.2.5:52183），说明已生效；若出现主机名，说明还在查
最易被忽略的是：改完配置不验证是否真正生效，就以为问题解决了。而权限表没同步更新，会导致生产环境突然连不上——这种故障往往发生在半夜重启之后。
