mysql中修改用户密码与权限更新的实践

mysql 8.0+ 修改密码须用 ALTER USER，不可 UPDATE；必须指定主机名并满足密码策略；权限变更后需显式执行 FLUSH PRIVILEGES；创建用户与授权应分离；远程访问需检查 bind-address、防火墙及云安全组。

MySQL 8.0+ 修改用户密码必须用 ALTER USER

MySQL 5.7 以前还能用 UPDATE mysql.user 直接改 password 字段，8.0 起字段名变成 authentication_string，且密码哈希逻辑变了，直接 UPDATE 会导致用户无法登录。最稳妥的方式是走官方授权语句：

ALTER USER 'myuser'@'localhost' IDENTIFIED BY 'NewPass123!';

注意两点：
• 必须带主机名（如 'myuser'@'localhost'），不能只写用户名
• 密码要满足默认的密码策略（至少 8 位、大小写字母+数字+特殊字符），否则报错 Error 1819 (HY000)

如果策略太严想临时放宽，可执行：

SET GLOBAL validate_password.length = 6;
SET GLOBAL validate_password.policy = LOW;

修改权限后必须显式执行 FLUSH PRIVILEGES

用 GRANT 或 REVOKE 改完权限，MySQL 不会自动重载内存中的权限缓存。不刷新的话，新权限对已连接的会话无效，新连接也可能延迟生效（取决于缓存刷新时机）。

正确流程是：

• 先执行权限变更语句，例如：

  GRANT SELECT, INSERT ON mydb.* TO 'myuser'@'localhost';

• 再立即执行：

  FLUSH PRIVILEGES;

常见误区：以为 GRANT 自带刷新，或只在 MySQL 重启后才生效 —— 实际上不 FLUSH，哪怕断开重连，权限仍可能沿用旧缓存。

CREATE USER 和 GRANT 分开执行更可控

很多教程把创建用户和赋权写成一条 GRANT ... TO 'u'@'h' IDENTIFIED BY 'p'，这在 MySQL 8.0+ 已被标记为过时语法，且隐含风险：

• 如果用户已存在，该语句会静默失败（不报错但不生效）
• 密码策略检查发生在 GRANT 阶段，失败时难以定位是创建问题还是授权问题
• 无法单独控制账号锁定状态（ACCOUNT LOCK）或密码过期（PASSWORD EXPIRE）

推荐拆解：

CREATE USER 'myuser'@'localhost' IDENTIFIED BY 'Pass123!' PASSWORD EXPIRE NEVER ACCOUNT UNLOCK;
GRANT SELECT ON mydb.users TO 'myuser'@'localhost';
FLUSH PRIVILEGES;

远程访问用户要注意 host 值和防火墙

给远程用户授权时，'myuser'@'%' 看似方便，但实际常踩两个坑：

• MySQL 默认绑定 127.0.0.1，需确认 bind-address 在 /etc/mysql/mysql.conf.d/mysqld.cnf 中设为 0.0.0.0 或具体内网 IP
• linux 防火墙（如 ufw）默认拦掉 3306 端口，得手动放行：

  sudo ufw allow 3306

• 云服务器（如阿里云、AWS）还有安全组规则，必须额外配置入方向 TCP:3306

验证是否生效，别只在本地连，用另一台机器跑：

mysql -h your-server-ip -u myuser -p

，否则容易误判权限配置成功。

权限更新不是改完就完的事，FLUSH PRIVILEGES 这一步漏掉，问题会卡在“明明给了权限却没效果”的模糊地带；而远程访问的层层拦截，往往让人反复怀疑 SQL 写错了。