MySQL 启动慢通常卡在 DNS 反向解析，需检查错误日志中“Resolving”或“getaddrinfo”关键词；启用 skip-name-resolve 可解决但须置于 [mysqld] 段，并改用 IP 授权。
MySQL 启动慢？先看错误日志里有没有 Resolving 卡点
很多“数据库开机慢”实际是启动时卡在 DNS 反向解析上，而不是磁盘或配置加载慢。MySQL 服务启动初期会尝试解析本地主机名（比如 localhost 或服务器 hostname），若系统 DNS 配置异常、/etc/hosts 缺失对应条目，或启用了不稳定的 DNS 服务器，就会阻塞数秒甚至更久。
- 立刻检查 MySQL 错误日志（路径通常是
/var/log/mysql/error.log或/var/lib/mysql/*.err），搜索关键词Resolving或getaddrinfo - 常见报错片段：
2026-03-12T19:01:22.123456Z 0 [Note] Skipping generation of SSL certificates.后面长时间无日志，接着突然出现2026-03-12T19:01:28.789012Z 0 [Note] Server socket created on IP: '0.0.0.0'.—— 中间这 6 秒空档大概率就是 DNS 卡住 - 不要只盯着
mysqld_safe日志，mysqld自身的 error log 才是真相来源
skip-name-resolve 必须加在 [mysqld] 段，且不能写错位置
关闭 DNS 反向解析最直接有效的方式就是启用 skip-name-resolve，但它极易因配置位置错误而失效。
- 必须放在
[mysqld]段内，写在[client]、[mysql]或文件开头全局区都无效 - 确认配置文件路径：Linux 下优先检查
/etc/my.cnf和/etc/mysql/my.cnf；Docker 容器中常挂载到/etc/mysql/conf.d/下的自定义 .cnf 文件 - 加完后务必重启服务：
sudo systemctl restart mysql（注意不是mysqld，CentOS 8+/Debian 11+ 服务名已统一为mysql） - 验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'skip_name_resolve';"，返回ON才算成功
开了 skip-name-resolve 后，GRANT 语句里的主机名会失效
这是最常被忽略的副作用：一旦启用 skip-name-resolve，MySQL 就不再做任何 DNS 解析，所有授权必须使用 IP 地址或 '%'，不能再依赖主机名匹配。
- 原授权：
GRANT SELECT ON db.* TO 'user'@'webserver.example.com';→ 启用后该用户将无法连接 - 正确做法：改用 IP，如
'user'@'10.10.20.5'；或放宽为'user'@'%'（需配合防火墙控制） - 检查现有授权：
SELECT host,user FROM mysql.user;，重点关注非'localhost'和非'%'的 host 值 - 如果业务强依赖域名白名单，就不能开
skip-name-resolve，得换思路：优化本地/etc/hosts，确保 hostname 能快速正向 / 反向解析
别只盯 DNS，启动慢还可能是 innodb_recovery 或大表 crash-safe 初始化
如果关了 skip-name-resolve 启动仍慢，问题可能在存储引擎层——尤其是 InnoDB 在崩溃恢复或首次加载大表元数据时的同步阻塞。
- 查看错误日志中是否有
InnoDB: Starting crash recovery、Waiting for purge to start或反复出现的Opening tables日志 - 特别留意
innodb_force_recovery > 0的配置，它会让启动过程变慢且跳过部分校验 - 大表（尤其千万级以上）的
.frm+.ibd元数据扫描在旧版本 MySQL（5.7 以前）中是单线程同步操作，升级到 MySQL 8.0+ 并启用innodb_read_only（仅读实例）可缓解 - 临时诊断：启动时加参数
--log-error-verbosity=3，让日志输出更细粒度的初始化步骤耗时
真正卡住 MySQL 启动的，往往不是那几行配置，而是你没看到的 DNS 超时等待，或者一条被遗忘的 GRANT 语句正在默默拒绝所有连接。
