MySQL 修改密码不会自动改变用户权限
改密码只是更新
mysql.user表里的
authentication_string（或旧版本的
Password）字段，不触碰
Grant_priv、
Select_priv等权限字段，也不重载权限缓存。用户登录后能执行什么操作，完全取决于当前已授予的权限，和密码本身无关。
但改密码方式选错可能间接导致权限“失效”
常见误操作包括：
用SET PASSWORD或
ALTER USER ... IDENTIFIED BY时指定了错误的
HOST（比如把
'user'@'localhost'写成
'user'@'%'），结果修改了另一个同名但 host 不同的账户，原账户密码没变，新账户无权限 用
UPDATE mysql.user SET authentication_string = ... WHERE User='xxx'直接更新但忘了
FLUSH PRIVILEGES，导致权限表未重载，新密码能登录但权限读取异常（极少见，但存在缓存不一致风险） 在 MySQL 8.0+ 中用
ALTER USER ... IDENTIFIED WITH caching_sha2_password BY 'xxx'强制指定插件，而客户端不支持该认证方式（如老版本 MySQL Connector/J），会报
Public Key Retrieval is not allowed或直接拒绝连接——看起来像“没权限”，其实是认证失败
验证权限是否真变了，别只看能不能登录
登录成功 ≠ 权限正常。应显式检查：
SHOW GRANTS FOR 'username'@'host';
注意必须带完整
host，否则可能查到默认匹配规则下的错误账户。如果返回空或只有
USAGE，说明权限确实被清空过（比如之前执行过
DROP USER再重建但没重新授权）。
常见混淆点：
CREATE USER 'u'@'%' IDENTIFIED BY 'p';只建用户，不赋任何权限（连
SELECT都没有）
GRANT SELECT ON db.* TO 'u'@'%';不加
WITH GRANT OPTION，该用户就不能再转授权限 MySQL 8.0 默认启用
sql_mode=STRICT_TRANS_TABLES，若用旧语法
INSERT INTO mysql.user手动插数据，可能因字段缺失或类型不匹配导致插入失败或静默截断
真正影响权限感知的，是认证插件与连接方式的组合
MySQL 用户权限生效的前提是：认证通过 + 权限表加载正确 + SQL 模式允许对应操作。例如：
用户用caching_sha2_password插件认证，但客户端连接时未设
?allowPublicKeyRetrieval=true&useSSL=false，连接直接中断，根本走不到权限检查阶段 用户 host 是
'192.168.1.%'，但应用连的是
127.0.0.1（解析为
'user'@'127.0.0.1'），而该 host 下没授权，就会报
Access denied—— 这不是密码或权限变了，是匹配不到账户 使用 Unix socket 登录（
localhost）时，MySQL 会忽略 TCP/IP 的
'user'@'%'，优先匹配
'user'@'localhost'；换用
127.0.0.1就走 TCP，行为完全不同
这些细节不写进日志，也不报明确错误，最容易让人以为“改完密码权限就没了”。
