从命令提示符和MySQL Workbench连接Azure Database for MySQL无响应

问题排查方案 #

1. 优先排查连接参数缺失问题 #

Azure Database for MySQL的连接要求和本地MySQL有差异，多数此类问题都是参数不全导致：

• 命令行连接请补全参数，执行命令：
  mysql -h <你的Azure MySQL实例域名> -u <完整用户名，格式为「用户名@实例名」> -p --ssl-mode=DISABLED -P 3306
  即使服务端已经关闭SSL强制校验，8.0版本的本地MySQL客户端默认会发起SSL协商，加上--ssl-mode=DISABLED参数可跳过该流程，避免协商卡住。
• MySQL Workbench配置修改：新建连接时打开SSL标签页，将「Use SSL」选项设置为「否」，同时确认用户名填写了完整的「用户名@实例名」格式，端口为默认3306。

2. 排查DNS解析与IPv6问题 #

部分地区网络环境下，Azure MySQL的域名会优先解析到IPv6地址，若本地IPv6链路不通会直接导致连接无响应：

• 本地执行nslookup <你的Azure MySQL实例域名>，查看返回的IP地址，优先使用返回的IPv4地址作为连接地址测试。
• 可直接在本地hosts文件中添加绑定规则，将实例域名指向解析得到的IPv4地址，强制走IPv4链路。

3. 排查网络出口与代理问题 #

若上述步骤无效，可验证本地直连3306端口的连通性：

• 执行telnet <你的Azure MySQL实例域名> 3306，若命令执行后长时间无返回，说明本地网络运营商或者路由器封禁了3306端口的出口流量。
• 检查DBeaver是否配置了代理服务，若DBeaver走代理可通，命令行和Workbench直连不通，即可确认是3306端口被封，可通过配置代理、更换网络环境，或者联系运营商解除端口限制解决。

4. 排查客户端版本兼容性 #

若本地安装的MySQL命令行客户端、Workbench版本低于8.0.20，可能存在和Azure MySQL 8.0的兼容性问题，尤其是默认认证插件caching_sha2_password的适配问题，升级客户端到最新8.0稳定版即可解决。

内容的提问来源于stack exchange，提问作者ecormaksin