修改密码不会改变用户权限，仅更新authentication_string字段；权限取决于GRANT语句授予的内容及host匹配、认证插件兼容性、权限缓存是否刷新等因素。
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，行为完全不同
这些细节不写进日志，也不报明确错误，最容易让人以为“改完密码权限就没了”。
