开启skip-name-resolve后域名授权账号失效是正常行为，因MySQL跳过反向DNS解析，仅支持IP或%匹配；需手动UPDATE mysql.user将Host字段从域名改为IP或%，再执行FLUSH PRIVILEGES生效。
skip-name-resolve 开启后，授权失效不是配置错了，是它本来就会这样——MySQL 不再做反向 DNS 解析，user@host 中的 host 就只能匹配 IP 或 %，域名直接不认。
为什么开了 skip-name-resolve 后账号登不上？
服务端启用 skip-name-resolve = ON 后，MySQL 在认证阶段跳过 gethostbyaddr() 调用，也就不再把客户端 IP 反查成主机名。这意味着：
- 原来用
'app'@'web01.example.com'创建的账号，现在完全无法匹配——哪怕客户端真是从 web01 连过来的 -
HOST列在information_schema.PROCESSLIST里只会显示 IP（如10.0.2.5:42193），不会出现域名 - 权限系统只按字面值比对：IP 必须完全一致，或用
%通配；'app'@'localhost'和'app'@'127.0.0.1'是两个不同账号，互不覆盖
怎么修复已失效的域名授权账号？
不能靠“重载权限”或“重启 MySQL”恢复，必须显式更新权限表。操作分三步：
- 查出问题账号：
SELECT User, Host FROM mysql.user WHERE Host LIKE '%example.com%'; - 把域名改成对应 IP（或改用
%）：UPDATE mysql.user SET Host = '10.0.2.5' WHERE User = 'app' AND Host = 'web01.example.com'; - 刷新权限：
FLUSH PRIVILEGES;
注意：UPDATE 后要确认生效，执行 SELECT Host FROM mysql.user WHERE User = 'app'; 看是否已更新；如果客户端 IP 是动态分配（比如 Kubernetes Pod），硬写 IP 不可持续，此时应评估是否真能关掉反查。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
如何验证 skip-name-resolve 是否真正生效？
别只看配置文件有没有加、MySQL 有没有重启——得看运行时行为：
- 连上 MySQL 后执行：
SELECT @@skip_name_resolve;，返回1才算开启成功 - 执行
SHOW PROCESSLIST;，观察Host列：如果全是 IP 地址（如192.168.1.10:54321），没有web01.example.com这类字符串，说明解析确实被跳过 - 临时停掉本机 DNS 服务（如
sudo systemctl stop systemd-resolved），再连一次；如果延迟消失，基本锁定是 DNS 反查导致的卡顿
客户端用域名连接，skip-name-resolve 能解决吗？
不能。这个参数只影响服务端对客户端 IP 的反向解析，对客户端自己解析 host=database-prod 这种正向 DNS 查询毫无作用。
- 如果你的连接串里写的是
-h db.example.com，慢是因为本地/etc/resolv.conf配置的 DNS 响应慢，或者该域名没配好记录 - 验证方式：
time nslookup db.example.com或time host db.example.com，耗时高就说明是客户端侧 DNS 问题 - 临时解法：加 hosts 映射，或直接改连接串为 IP；长期方案是优化 DNS 配置，而不是指望 MySQL 配置来兜底
真正容易被忽略的点是：你改了配置、也重启了 mysqld，但没检查 @@skip_name_resolve 的运行时值，也没看 PROCESSLIST 的 Host 列——结果误以为问题已解决，其实授权还在失效状态。
