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

来源：这里教程网时间：2026-02-28 20:44:15 作者：

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;<br>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;<br>GRANT SELECT ON mydb.users TO 'myuser'@'localhost';<br>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

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