使用MySQL Workbench进行数据迁移向导时报连接超时如何处理

根本原因是迁移向导启动时反向校验目标库连通性，而非源库连接问题；需检查目标MySQL的bind-address是否为0.0.0.0、防火墙/安全组是否放行3306端口、SSH隧道配置是否误启用，并可通过connections.xml调大connection_timeout参数临时缓解。

MySQL Workbench 迁移向导报 Connection timeout 的根本原因

这不是网络不通的简单问题，而是迁移向导在启动阶段会尝试用源库的连接参数（尤其是 host、port、user）反向连接目标库或自身所在机器，用于校验 SSH 隧道、SSL 配置或元数据服务端口。如果目标 MySQL 实例监听的是 127.0.0.1 而非 0.0.0.0，或者防火墙/云安全组没放行目标端口（默认 3306），就会卡在“Testing connection…”并最终超时。

关键点：这个超时和你能否用 Workbench 正常连上源库完全无关——它测的是迁移流程内部的连通性链路。

检查并修正目标 MySQL 的 bind-address 和防火墙

• 确认目标 MySQL 配置中 bind-address 不是 127.0.0.1（否则只接受本地回环连接）；应设为 0.0.0.0 或具体可访问的内网 IP
• 在目标服务器上运行 sudo ss -tlnp | grep :3306，确认监听地址不是 127.0.0.1:3306
• 云环境（如 AWS/Aliyun）必须检查安全组规则，确保入方向允许来源 IP（即你运行 Workbench 的机器 IP）访问 3306
• 本地测试时若目标 MySQL 是 Docker 容器，需加 -p 3306:3306 并确认容器内 bind-address 配置正确

绕过 SSH 隧道自动检测（常见于远程目标库场景）

迁移向导默认勾选 Use SSH tunnel 时，即使你没填 SSH 参数，它仍会尝试建立隧道并等待响应，极易触发超时。

• 在迁移向导第一页（Source Selection）点击 Manage Connections…
• 编辑目标连接，在 SSH 标签页中：
  • 取消勾选 Use SSH tunnel
  • 确保 Connection Method 是 Standard TCP/IP
  • 如果目标库确需 SSH 访问，手动填入完整 SSH 主机、端口、用户、密钥路径，并在 MySQL Hostname 填 127.0.0.1（因为 SSH 隧道会在本地映射）

调整 Workbench 内部超时阈值（临时应急）

Workbench 没有图形界面选项调这个值，但可通过修改配置文件生效：

• 关闭 Workbench
• 找到配置文件：~/.mysql/workbench/connections.xml（macOS/Linux）或 %APPDATA%MySQLWorkbenchconnections.xml（Windows）
• 在对应连接节点下添加或修改：<parameter name="connection_timeout">60</parameter>（单位秒，建议从 30 改成 60 或 120）
• 重启 Workbench 后重试

注意：该参数仅影响部分连接阶段，不能解决底层不可达问题，只是给慢链路多一点时间。

迁移向导的连接校验逻辑藏得深，很多用户反复确认“我能连上”，却没意识到它其实在用另一套路径探测——最稳妥的做法永远是先用 mysql -h 目标IP -P 3306 -u 用户 -p 在 Workbench 所在机器上手动连一次目标库。