许多用户在使用 MySQL Workbench 进行数据迁移时，常常在“Connection timeout”报错处停滞不前，第一反应往往认定是源数据库无法连接。但问题实际上更多出在迁移向导启动时执行的那次“反向校验”——它会沿用源库的连接参数，主动去探测目标数据库或自身所在的机器，验证 SSH 隧道、SSL 配置或元数据端口是否畅通。如果目标 MySQL 仅监听 127.0.0.1，或者防火墙、安全组未放行 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、阿里云）务必核对安全组规则，确保入方向允许运行 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%\MySQL\Workbench\connections.xml（Windows）。 - 在对应连接节点下添加或修改
60 - 重启 Workbench 后重新尝试迁移。
注意：该参数仅影响部分连接阶段，无法解决底层网络不可达的问题，但能为较慢的链路争取额外时间。
迁移向导的连接校验逻辑较为隐蔽，许多用户反复确认“我能连上源库”，却未曾意识到它实际采用了另一套路径去探测目标。最稳妥的做法始终是：在 Workbench 所在机器上手动执行 mysql -h 目标IP -P 3306 -u 用户 -p，亲自连接一次目标库，确认网络可达且权限配置正确。
