执行select @@skip_name_resolve;返回0说明未跳过dns解析，需在[mysqld]段添加skip-name-resolve=on并重启mysql，此后授权必须改用ip或%。
查 skip_name_resolve 是否关闭
MySQL 服务端默认会对每个新连接的客户端 IP 做反向 DNS 解析，如果 DNS 不可用、响应慢或客户端 IP 没配 PTR 记录，就会卡住几秒甚至更久——你看到的“连不上”“卡在密码输入后”，八成是卡在这儿。
执行 SELECT @@skip_name_resolve;，返回 0 就说明没跳过解析。立刻改配置：
- 编辑
/etc/my.cnf或/etc/mysql/my.cnf，在[mysqld]段下加一行：skip_name_resolve = ON - 重启 MySQL：
systemctl restart mysql - 注意：此后所有
GRANT必须用 IP 或%，比如'user'@'10.20.30.40'，不能再写'user'@'webapp.local'
看 Threads_connected 和 Threads_running 差值
这个差值比慢日志还早暴露问题。它不反映 SQL 多慢，而反映“有多少连接在排队等干活”。
执行 SHOW GLOBAL STATUS LIKE 'Threads_%';：
- 若
Threads_connected远大于Threads_running（比如 200 vs 5），说明大量连接空挂着，大概率是应用没 close、连接池泄漏或wait_timeout设得太小 - 若两者接近且持续 >50，说明并发压过处理能力，不是单条 SQL 慢，是整体吞吐见顶
- 检查当前超时值：
SELECT @@wait_timeout, @@interactive_timeout;；云数据库常设为 300 秒，但客户端连接池若没配validation-timeout或connection-test-query=SELECT 1，就会反复拿到已断开的假连接
抓包确认卡在 DNS 还是 TCP 层
用 tcpdump 能一眼区分问题层级：如果三次握手完成之后，长时间没有后续数据包，基本就是 DNS 卡住；如果有大量重传或 SYN 包无响应，则是网络或防火墙问题。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
在 MySQL 服务端执行：
-
tcpdump -i any port 3306 -w mysql_conn.pcap，然后复现一次慢连接 - 用 Wireshark 打开 pcap，看 client SYN → server SYN-ACK → client ACK 后是否停顿 ≥1s
- 若停顿，再在客户端测 DNS：
time nslookup your-mysql-host或time host your-mysql-host - 临时绕过：把 MySQL 地址写进
/etc/hosts，或客户端直连 IP（如mysql -h 10.20.30.40 -u user -p）验证是否立刻连上
别被 -A 和 SSL 掩盖真实瓶颈
mysql -h ... -u ... -p -A 连得快，不代表连接本身快——-A 只是禁用了元数据预加载（SHOW TABLES 等），掩盖了“连上之后初始化慢”的问题；而 --ssl-mode=DISABLED 成功，也不代表 SSL 是元凶，可能只是它让连接从 8 秒缩到 5 秒，但根本问题仍在 DNS 或连接池复用不足。
真正要盯的是连接建立阶段的行为：
- PHP 应用高频新建连接？确认是否用了
mysqli::pconnect()或 PDO 的PDO::ATTR_PERSISTENT - Java 应用用 HikariCP？检查
minimumIdle是否设太高导致空闲连接被回收后重连触发 DNS - 云环境要注意 NAT 网关的 TCP 空闲超时（常为 300 秒），它比 MySQL 的
wait_timeout更早断连，且不会通知客户端
最易被忽略的一点：很多团队花半天调优 SQL，却没查过 SELECT USER(), CURRENT_USER(); 返回的 host 是域名还是 IP——这行命令就能直接告诉你 DNS 解析有没有生效，比翻日志快十倍。
