直接修改mysql.user表host字段为%常失败，须同时满足MySQL 5.7权限模型、my.cnf中bind-address=0.0.0.0（或指定IP）、防火墙/云安全组放行3306端口三者；应优先用GRANT语句授权并执行FLUSH PRIVILEGES，且需区分localhost与127.0.0.1。

直接改 mysql.user 表的 host 字段为 % 是最常见做法，但仅这一步大概率失败——因为 MySQL 5.7 的权限模型、配置文件限制和防火墙三者必须同时满足，缺一不可。

确认 root 用户当前 host 策略是否真为 localhost

很多用户跳过这步就直接执行 UPDATE，结果发现没生效，或者改完后本地也连不上了。先查清楚现状：

• 登录 MySQL：mysql -u root -p
• 执行：USE mysql;，再运行 SELECT User, Host FROM user WHERE User = 'root';
• 如果只看到 localhost，说明远程连接被明确拒绝；如果已有 % 或具体 IP，问题可能出在其他环节

注意：localhost 和 127.0.0.1 在 MySQL 权限中是两个不同 host，前者走 socket 连接，后者走 TCP，不能互相替代。

用 GRANT 替代 UPDATE 更安全可靠

MySQL 5.7 推荐用授权语句而非直接更新系统表，避免破坏默认账户结构（比如误改 mysql.session 或 mysql.sys）：

• 允许任意主机以 root 连接（仅测试环境）：GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'your_password' WITH GRANT OPTION;
• 更推荐指定 IP：GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.100' IDENTIFIED BY 'your_password' WITH GRANT OPTION;
• 执行 FLUSH PRIVILEGES; 生效（UPDATE 后也必须做这步，否则权限不加载）

如果报错 ERROR 1819 (HY000)，说明密码强度不满足策略，需先执行：SET GLOBAL validate_password_policy=LOW;（临时放宽）

检查 my.cnf 中 bind-address 是否监听外部地址

即使权限开了，MySQL 默认只监听 127.0.0.1，远程请求根本到不了服务端：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 找到配置文件（通常为 /etc/my.cnf 或 /etc/mysql/my.cnf）
• 确认存在且未被注释的行：bind-address = 0.0.0.0（监听所有接口）或 bind-address = 公网IP
• 不要写成 bind-address = 127.0.0.1，这是远程连接失败的高频原因
• 修改后重启服务：sudo systemctl restart mysql（Ubuntu/Debian）或 sudo service mysqld restart（CentOS）

重启后可用 netstat -tlnp | grep :3306 验证监听地址是否为 *:3306，不是 127.0.0.1:3306。

防火墙与云服务商安全组常被忽略

本地 telnet 能通 3306 ≠ MySQL 允许连接，只是端口开放了；但若防火墙或安全组没放行，请求压根进不来：

• Linux 防火墙（ufw）：sudo ufw allow 3306
• firewalld：sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload
• 阿里云/腾讯云等平台：必须单独在控制台配置“安全组规则”，添加入方向 TCP 3306，源 IP 建议填具体客户端 IP，而非 0.0.0.0/0

最容易踩的坑是：本地测试时关了防火墙，上云服务器后忘了配安全组——此时错误现象和权限问题完全一致，但排查方向完全不同。

真正卡住人的往往不是某一步操作错了，而是多个环节里有一个没到位：比如 GRANT 写对了，my.cnf 没改，或者安全组开着但只允许 HTTP 流量。建议按“权限 → 配置 → 网络”顺序逐项验证，别跳步。