MySQL用户表host字段是登录匹配依据，非白名单；需精确匹配连接IP，如'%'不包含localhost，远程访问须建对应host用户并执行FLUSH PRIVILEGES生效。
MySQL用户表的host字段到底填什么
远程连不上，八成是host字段没配对。它不是“允许从哪来”的白名单，而是mysql判断“这个用户名能不能从某ip登录”的硬匹配字段。
常见错误：只执行CREATE USER 'root'@'localhost'，却想用root从另一台机器连——localhost不等于127.0.0.1，更不等于%。
-
'user'@'localhost'：仅限本机socket或显式指定--protocol=socket连接 -
'user'@'192.168.1.%'：匹配该网段所有IPv4地址（注意不能写192.168.1.*） -
'user'@'%'：匹配任意IPv4/IPv6主机，但%不包含localhost（MySQL 8.0+默认行为） - 若需同时支持本地socket和远程TCP，得建两个用户：
'user'@'localhost'+'user'@'%'
GRANT语句必须带WITH GRANT OPTION吗
不需要。这个选项只影响“能否把权限再授给别人”，和远程访问本身无关。真正卡住远程连接的，是授权时是否指定了正确的host，以及是否刷新了权限缓存。
典型误操作：运行GRANT ALL ON *.* TO 'dev'@'192.168.5.100'后直接试连，结果失败——因为MySQL没立刻生效。
- 执行
GRANT后必须跟FLUSH PRIVILEGES（除非你用的是MySQL 8.0+且只操作mysql.user表，但依然建议刷） -
GRANT本身不会创建用户，如果用户不存在，要先CREATE USER或用GRANT ... IDENTIFIED BY - MySQL 8.0起密码策略变严，
IDENTIFIED BY的密码必须满足validate_password要求，否则报错ERROR 1819 (HY000)
my.cnf里bind-address设成0.0.0.0就万事大吉？
不是。这只是让MySQL监听所有IPv4地址，但还卡在三道关：防火墙、云厂商安全组、MySQL自身的host校验。
常见现象：telnet your-server-ip 3306不通，第一反应改bind-address，却忘了服务器iptables或ufw根本没放行3306端口。
- Linux上检查：运行
sudo ufw status或sudo iptables -L -n | grep 3306 - 阿里云/腾讯云等平台，安全组规则必须显式添加入方向TCP:3306，源IP不能只写
0.0.0.0/0（过于宽松），建议限定来源IP段 -
bind-address = ::可同时监听IPv4和IPv6，但多数内网环境用不到，0.0.0.0已足够 - 改完
my.cnf必须重启MySQL：sudo systemctl restart mysql（Ubuntu）或mysqld（CentOS）
连接时提示Host 'x.x.x.x' is not allowed to connect to this MySQL server
这是MySQL在mysql.user表里完全没找到匹配的user@host记录，不是密码错，也不是端口问题，是“身份根本不在系统里”。
别急着删用户重来，先查清楚当前有哪些用户能连：
SELECT user, host FROM mysql.user;
再确认你连接时用的用户名和目标IP，是否和其中某一行严格一致（注意大小写、空格、%通配符位置）。
- 如果看到
'admin'@'192.168.10.%'，但从192.168.11.5连，就会触发这个错误 - MySQL 8.0+默认禁用
root远程，即使你手动改了host，也可能因plugin字段是caching_sha2_password导致客户端不兼容（老版本MySQL Workbench或PHP mysqli可能连不上） - 临时救急可用
UPDATE mysql.user SET host='%' WHERE user='xxx'; FLUSH PRIVILEGES;，但生产环境严禁对root这么干
最常被忽略的一点：改完mysql.user表后，必须FLUSH PRIVILEGES，否则变更只存在内存副本里，MySQL重启就丢。
