直接修改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;（临时放宽）
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
检查 my.cnf 中 bind-address 是否监听外部地址
即使权限开了，MySQL 默认只监听 127.0.0.1，远程请求根本到不了服务端：
- 找到配置文件（通常为
/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 流量。建议按“权限 → 配置 → 网络”顺序逐项验证，别跳步。
