mysql启动卡在“resolving host…”是因mysqld对绑定ip调用gethostbyaddr()做ptr反向解析，dns不可达或无ptr记录时默认等待30秒；验证方法包括停dns服务后重启mysql、用::1测试ipv6响应、查processlist的host列是否全为ip，且skip_name_resolve=on必须写在[mysqld]段、完整重启并select @@skip_name_resolve确认生效。
启动卡在“Resolving host…”怎么确认是DNS反向解析？
这不是配置写错了，也不是磁盘慢，而是mysqld进程在初始化监听时，对绑定的每个IP（包括127.0.0.1）调用gethostbyaddr()做PTR查询。若DNS不可达或内网没配反向记录，它会等满默认30秒才放弃。
快速验证方法：
- 临时停掉DNS服务：
sudo systemctl stop systemd-resolved，再systemctl restart mysql，如果启动变快，基本锁定问题 - 用IPv6回环测试：
mysql -h ::1 -u root -p，如果IPv4卡顿但IPv6立即响应，说明IPv4反查阻塞 - 查
information_schema.PROCESSLIST：如果HOST列全是IP（如10.0.2.5:52183），说明已跳过解析；若出现主机名，说明还在查
skip_name_resolve = ON为什么加了也不生效？
这个参数必须严格满足三个条件才起作用，缺一不可：
- 必须写在
[mysqld]段内——写在[client]、[mysql]或文件开头都无效 - 必须完整重启：
systemctl restart mysql（reload不重载该参数） - 要确认最终加载路径：运行
mysqld --verbose --help | grep "Default options"，看是否被!includedir /etc/mysql/conf.d/下其他文件覆盖
验证是否真正生效：SELECT @@skip_name_resolve;返回ON才算成功。别只改配置就以为完事，很多故障发生在半夜重启后权限突然失效——因为授权表里还留着'app'@'web01.example.com'这种域名，而启用后只认IP或%。
启动慢但Seconds_Behind_Master不是原因
主从延迟是运行时问题，和安装后首次启动慢无关。你看到的启动延迟，90%以上来自以下环节：
-
InnoDB崩溃恢复：如果上次是kill -9或断电关机，启动时会扫描redo log并重放脏页，日志越大、脏页越多、磁盘越慢，耗时越长 - 插件初始化：比如
validate_password、audit_log这类低频插件，在启动阶段做校验或加载，拖慢节奏 - 系统级干扰：SELinux/AppArmor拦截文件访问、NFS挂载点卡住、
/var/lib/mysql所在磁盘I/O饱和（用iostat -x 1看%util是否持续>90%）
查error log最直接：grep -i "crash\|recovery\|plugin" /var/log/mysql/error.log，有Starting crash recovery就说明在做InnoDB恢复，不是DNS问题。
改完配置后连接突然失败，最容易漏哪一步？
开了skip_name_resolve = ON后，所有GRANT语句里的主机名都会失效。但很多人只改配置，忘了同步清理权限表。
必须执行：
- 查隐患账号：
SELECT User, Host FROM mysql.user WHERE Host NOT IN ('%', '127.0.0.1', '::1', 'localhost'); - 批量更新：
UPDATE mysql.user SET Host = '%' WHERE Host = 'web01.example.com';（或精确到具体IP） - 刷新权限：
FLUSH PRIVILEGES;
Kubernetes等动态IP环境慎用硬编码IP——Pod每次重启IP都变，这时应评估是否真能关反查，而不是盲目加参数。复杂点永远不在配置本身，而在改完之后，有没有人去检查权限表是否还残留着旧的域名规则。
