直接原因是权限系统找不到匹配的认证记录，因UPDATE未同步更新authentication_string、plugin等字段，导致认证失败而非密码清空。
MySQL 8.0+ 中 UPDATE user SET host = '%' 会导致密码失效的直接原因
这不是密码“被清空”，而是 MySQL 权限系统彻底找不到匹配的认证记录。当你执行 UPDATE mysql.user SET host = '%' WHERE user = 'root' AND host = 'localhost';，本质是把一条 'root'@'localhost' 记录强行改成 'root'@'%'，但以下字段往往没同步更新：
-
authentication_string字段可能仍为空（尤其在旧迁移数据中），导致认证时无密码可比对 -
plugin字段常残留为caching_sha2_password，而客户端（如 Navicat、旧版 Python MySQL 驱动）不支持该插件，直接拒绝握手 -
account_locked或password_expired字段可能被隐式置为Y，因绕过正常 ALTER USER 流程，状态未重置
结果就是：连接请求能抵达 MySQL，但认证阶段卡在“用户存在但无法验证”——报错可能是 ERROR 1045 (28000): Access denied 或 ERROR 2059 (HY000)，而非 1130。
ALTER USER 'root'@'%' IDENTIFIED BY 'xxx' 为什么有时也不生效
因为 'root'@'%' 这条记录本身可能根本不存在，或者存在但被更高优先级记录拦截了。MySQL 匹配用户时按 host 的**最长前缀精确匹配**，不是查表顺序。常见陷阱：
- 你执行了
ALTER USER 'root'@'%'，但表里实际只有'root'@'127.0.0.1'和'root'@'localhost'—— 此时语句会报ERROR 1396 (HY000): Operation ALTER USER failed - 你成功创建了
'root'@'%'，但客户端连的是host.docker.internal，而 DNS 解析开启时，MySQL 把它反解成某个具体主机名（如web01.local），结果去匹配'root'@'web01.local'，而不是'%' -
FLUSH PRIVILEGES没执行，或执行了但 MySQL 启用了 PAM/LDAP 认证插件，内存缓存未刷新
真正安全改 Host 的三步操作顺序
别碰 UPDATE mysql.user，用授权语句闭环处理身份、密码、插件、权限四要素：
- 先确认目标记录是否存在：
SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root'; - 若
'root'@'%'不存在，用CREATE USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pwd';（显式指定插件兼容旧客户端） - 再授权：
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION; - 最后强制刷新：
FLUSH PRIVILEGES;（MySQL 8.0.16+ 可省略，但加了更稳）
如果只想保留本地访问又开放远程，不要改 localhost，而是并行建 'root'@'%' —— 两者互不干扰，localhost 走 socket，% 走 TCP，各司其职。
改完 Host 还连不上？必须检查的两个外部环节
权限只是第一关，漏掉下面任一环节，1130 错误照出不误：
-
bind-address仍为127.0.0.1：编辑/etc/mysql/mysql.conf.d/mysqld.cnf，把[mysqld]下的bind-address改成0.0.0.0或具体网卡 IP，然后sudo systemctl restart mysql - 防火墙拦了 3306：Ubuntu 用
sudo ufw allow 3306，CentOS 用sudo firewall-cmd --permanent --add-port=3306/tcp && sudo firewall-cmd --reload
最易被忽略的是：Docker 容器内应用连宿主 MySQL 时，-h 参数填的是 host.docker.internal，这个字符串会被 MySQL 当作 host 值去匹配 —— 所以你得有一条 'root'@'host.docker.internal' 记录，或者干脆用 '%' 并确保 DNS 不反解它。
