unauthenticated user是mysql连接已建立但卡在dns双向解析（ip→hostname→ip）验证环节所致，主因是反向解析超时或失败；解决需在[mysqld]段配置skip-name-resolve并重启，同时将授权语句中的主机名全部替换为ip或%。
MySQL 显示 unauthenticated user，绝大多数情况是 DNS 反向解析卡住导致的，不是权限或密码问题，也不是 MySQL 本身崩溃——加 skip-name-resolve 能立刻缓解，但必须同步调整授权方式。
为什么会出现 unauthenticated user？
这不是“用户没输密码”，而是连接已建立、但 MySQL 卡在验证环节：它拿到客户端 IP 后，试图调用 gethostbyaddr() 把 IP 反解成主机名，再调用 gethostbyname() 把主机名正向解析回 IP，做双向校验。只要其中一步慢（比如 DNS 服务器无响应、超时、或反向记录缺失），线程就卡在 login 状态，SHOW PROCESSLIST 就看到一堆 unauthenticated user。
常见诱因包括：
- DNS 服务器配置了但不可达，或客户端 IP 没有 PTR 记录
- /etc/hosts 里没补全客户端 IP 映射
- 高并发连接瞬间压垮 DNS 解析队列（尤其老版本 MySQL 用非线程安全函数时会全局锁）
skip-name-resolve 怎么配才生效？
必须写在 [mysqld] 段下，且不能带短横线前缀（--skip-name-resolve 是命令行参数写法，配置文件里要写成 skip-name-resolve）：
[mysqld] skip-name-resolve
配完必须重启 MySQL（systemctl restart mysql 或 service mysqld restart），热加载不生效。验证是否启用：SELECT @@skip_name_resolve; 返回 1 表示已开启。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
注意两个易错点：
- Windows 下配置文件通常是
my.ini，Linux 多为/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，别改错文件 - 如果 MySQL 启动时日志里出现
Unknown variable 'skip-name-resolve'，说明你写成了带双横线的形式，删掉即可
开了 skip-name-resolve 之后权限怎么设？
MySQL 不再解析主机名，所以所有 GRANT 语句里的 'user'@'hostname' 都会失效——哪怕你写了 'root'@'web01.example.com'，实际连接时用该主机 IP 连也会被拒绝。
必须全部改用 IP 或通配符：
- 允许某 IP：
GRANT ALL ON *.* TO 'app'@'192.168.10.5'; - 允许某网段：
GRANT SELECT ON db.t1 TO 'report'@'10.0.2.%'; - 允许任意 IP（慎用）：
GRANT ... TO 'dev'@'%'; -
特别注意 localhost 和 127.0.0.1 是两个不同 host：开了
skip-name-resolve后，'root'@'localhost'仍可用 Unix socket 连，但'root'@'127.0.0.1'必须显式创建，否则报错ERROR 1130 (HY000): Host '127.0.0.1' is not allowed to connect
还有哪些情况会导致 unauthenticated user？
skip-name-resolve 解决的是 DNS 卡顿主因，但不是唯一原因：
-
back_log值太小：当瞬时连接数超过max_connections，新连接会排队等待，队列满后也会表现为unauthenticated user；可适当调大back_log（需同步调高 OS 的net.core.somaxconn） - 客户端快速重连+认证失败：比如应用层未正确关闭连接、密码错误重试风暴，也可能堆积大量未完成认证的线程
- SELinux 或防火墙拦截了 DNS 查询路径（少见但真实存在，查
ausearch -m avc -ts recent）
真正棘手的是：DNS 解析失败有时不报错、不记日志，只默默卡住几秒——所以只要生产环境 MySQL 对外提供服务，skip-name-resolve 应该是默认选项，而不是等出问题再加。
