修改密码不会改变用户权限，仅更新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，行为完全不同

这些细节不写进日志，也不报明确错误，最容易让人以为“改完密码权限就没了”。