mysql如何配置主机名解析_mysql skip-name-resolve设置

应关闭 mysql 的 DNS 反向解析功能，即在 my.cnf 的 [mysqld] 段添加 skip-name-resolve 并重启服务；开启后需将授权语句中的域名 Host 改为 IP 或 %，并执行 FLUSH PRIVILEGES。

MySQL 启动卡在 Resolving host... 时该关什么

这是典型 DNS 反向解析阻塞，skip-name-resolve 就是解药。它让 MySQL 跳过对客户端 IP 做 gethostbyaddr() 的过程，直接用 IP 地址做权限匹配。

常见错误现象：
• 启动日志卡在 Starting MySQL... [ OK ] 却无响应
• mysql -h 192.168.1.100 -u root -p 连不上，但 localhost 可以
• 错误日志反复出现 Aborted connection ... because of host name resolution failure

• 只在 my.cnf 的 [mysqld] 段加一行：skip-name-resolve，别写错成 skip_name_resolve（下划线无效）
• 加完必须重启 MySQL，systemctl restart mysqld 或 service mysql restart
• 开启后，所有 GRANT 语句里的 HOST 值只能是 IP 或 %，不能再用域名（比如 'user'@'web01.example.com' 会失效）

为什么不能只靠 /etc/hosts 临时解决

/etc/hosts 确实能加速单机解析，但它治标不治本——只要 MySQL 没关 skip-name-resolve，它就仍会调用系统 DNS 接口，而一旦网络 DNS 不可用、超时或返回 NXDOMAIN，连接就会卡住或拒绝。

• 内网环境常有 DNS 服务未部署或配置错误，ping web01 成功不代表 MySQL 解析成功（MySQL 用的是反向解析，查 PTR 记录）
• /etc/hosts 无法覆盖所有客户端 IP，尤其容器或云主机 IP 动态分配时
• 某些发行版（如 centos Stream 9）默认启用 systemd-resolved，和 MySQL 解析逻辑存在竞态，比单纯 DNS 失败更难排查

skip-name-resolve 开启后权限怎么配才不翻车

原来用域名授权的账号会立即失效，必须重刷权限表。这不是 bug，是设计使然：关闭解析后，MySQL 根本不查域名，只认 IP 字符串。

• 检查现有授权：select User, Host FROM mysql.user;，把含域名的 Host 全记下来
• 批量转 IP：比如原为 'app'@'api-prod-01'，先 nslookup api-prod-01 拿到 IP，再执行 GRANT ... ON *.* TO 'app'@'10.10.20.5'
• 若需兼容多 IP 或动态环境，统一改用 'app'@'%'，但务必配合防火墙限制真实可连 IP 段
• 改完运行 FLUSH PRIVILEGES;，别漏掉这步

云环境或 docker 下还要注意这个点

容器网络或云 VPC 内，客户端 IP 经常是 NAT 后的地址（比如所有请求都显示为 172.17.0.1），这时即使开了 skip-name-resolve，权限控制粒度也会变粗。

• Docker 默认 bridge 网络里，宿主机连容器 MySQL，来源 IP 是 172.17.0.1，不是宿主机真实 IP
• 阿里云 RDS 或 AWS RDS 不允许改 my.cnf，也没法开 skip-name-resolve，得靠安全组 + 白名单 IP 控制访问
• kubernetes Pod 间通信若走 ClusterIP Service，MySQL 看到的 client IP 是 kube-proxy 的，不是原始 Pod IP——除非用 externalTrafficPolicy: Local 并直连 NodePort

真正麻烦的从来不是加一行配置，而是授权模型得跟着解析方式一起重想。IP 不稳定、NAT 层级多、容器编排抽象强——这些地方绕开 DNS 解析只是第一步，后面权限映射才是硬骨头。