直接用 root@'%' 远程连接 workbench 极其危险，因其将数据库最高权限暴露于公网，一旦密码泄露或被爆破，攻击者可执行删库、提权等高危操作；应创建指定出口 ip 的最小权限专用用户，并优先使用 ssh 隧道加密连接。
为什么直接用 root@'%' 连远程 Workbench 是危险操作
Workbench 本身不存储密码策略或权限边界，它只是把你的 SQL 权限原样转发给 MySQL。如果你在远程服务器上配置了 root@'%' 并开放了 3306 端口，等于把数据库的「最高管理员钥匙」挂在公网门口——只要密码泄露或被爆破，整个库就裸奔。真实事故里，80% 的数据泄露始于这类宽泛授权。
创建专用远程用户时必须指定 host 和最小权限集
不要跳过 CREATE USER 的 @'ip' 部分，也不要直接 GRANT ALL PRIVILEGES ON *.*。Workbench 连接用的不是你本地 IP，而是你实际发起连接的出口 IP（比如公司宽带出口、家用路由器公网 IP），这个 IP 要提前确认好。
- 用
curl ifconfig.me或访问 https://www.php.cn/link/46c4e6a9d4e1392f1f86747329e15ab0 查当前公网 IP - 执行
CREATE USER 'wb_admin'@'203.0.113.42' IDENTIFIED BY 'StrongPass!2026';（把203.0.113.42换成你的真实出口 IP） - 只授必要权限：
GRANT SELECT, INSERT, UPDATE, DELETE, SHOW VIEW ON `app_db`.* TO 'wb_admin'@'203.0.113.42'; - 执行
FLUSH PRIVILEGES;生效
Workbench 连接方式选 Standard TCP/IP 还是 SSH Tunnel？
除非你已确认远程 MySQL 服务启用了 TLS 且客户端证书已配好，否则别用裸 TCP/IP。Standard TCP/IP over SSH 是更稳妥的选择：它把所有流量封装进 SSH 加密通道，绕过 MySQL 自身的网络层暴露风险，也规避了 bind-address=0.0.0.0 带来的防火墙管理压力。
- SSH Hostname 填服务器公网 IP，Username 填能 SSH 登录的系统用户（如
ubuntu） - MySQL Hostname 必须填
127.0.0.1（不是服务器公网 IP！Workbench 是先 SSH 进去，再连本机 MySQL） - 如果 SSH 用密钥登录，勾选
Use key file并指定id_rsa路径；密码登录则填 SSH Password - 测试连接失败时，优先检查
ssh ubuntu@your-server-ip是否通，而不是立刻怀疑 MySQL 配置
Workbench 里改用户权限容易忽略的细节
Workbench 的 Users and Privileges 界面看起来直观，但它默认只显示 @'localhost' 用户。你刚创建的 'wb_admin'@'203.0.113.42' 不会自动出现在列表里，必须手动在 Filter 中输入完整用户名+host 才能定位到。
- 点击左下角
Refresh后，右上角搜索框输入wb_admin@203.0.113.42（注意带 @ 和 IP） - 修改权限后，Workbench 生成的 SQL 是
GRANT ... TO 'wb_admin'@'203.0.113.42'，但不会自动执行FLUSH PRIVILEGES—— 你得自己打开 SQL Editor 粘贴执行 - 删用户时，Workbench 默认只删
user表记录，但不会清理mysql.proxies_priv或mysql.role_edges（如果用了角色），建议仍用命令行DROP USER 'wb_admin'@'203.0.113.42';
真正麻烦的不是配置步骤，是你得同时盯住三处：MySQL 用户表里的 host 字符串是否精确匹配、SSH 隧道是否稳定、以及你本地出口 IP 是否被 ISP 动态更换过。一旦换 IP，'wb_admin'@'old-ip' 就立即失效——这不是 Workbench 的 bug，是权限模型的设计逻辑。
