修改MySQL用户密码不会自动改变权限，权限与密码字段相互独立；但密码修改方式可能影响认证插件，导致连接失败，推荐使用ALTER USER指定插件。
修改 MySQL 用户密码不会自动改变权限
单纯执行 ALTER USER 或 SET PASSWORD 修改密码，不会影响该用户已有的权限（如 SELECT、INSERT、GRANT OPTION 等）。权限信息存储在 mysql.user 表的权限列中，密码字段（authentication_string）和权限字段是相互独立的。
常见误解是“重置密码 = 重置账户状态”，其实不是。除非你显式执行 REVOKE 或 DROP USER 后重建，否则权限原封不动。
但密码修改方式会影响认证插件和登录能力
MySQL 8.0+ 默认使用 caching_sha2_password 插件，而老版本常用 mysql_native_password。用不同语句改密，可能意外切换插件，导致客户端连不上：
-
ALTER USER 'u'@'%' IDENTIFIED BY 'pw';—— 默认沿用当前认证插件，安全 -
SET PASSWORD FOR 'u'@'%' = 'pw';—— 在 8.0+ 中会强制切为mysql_native_password（若未显式指定插件），可能引发连接失败 - 直接 UPDATE
mysql.user表（不推荐）—— 容易漏掉FLUSH PRIVILEGES，且易写错authentication_string格式（必须是 SHA256 加密后的字符串）
验证当前插件：查 SELECT plugin FROM mysql.user WHERE user='u' AND host='%';
修改密码后需要 FLUSH PRIVILEGES 吗？
用 ALTER USER 或 CREATE USER 修改密码时，不需要 手动 FLUSH PRIVILEGES；MySQL 会自动重载权限缓存。只有当你绕过 SQL 接口、直接 UPDATE 系统表后，才需要它。
错误做法示例：UPDATE mysql.user SET authentication_string=PASSWORD('new') WHERE user='u'; —— PASSWORD() 函数在 8.0+ 已移除，且该写法不兼容新插件
正确做法始终优先用：ALTER USER 'u'@'%' IDENTIFIED WITH caching_sha2_password BY 'newpass';
特殊场景：匿名用户或空密码用户改密要格外小心
如果原用户是 ''@'localhost'（匿名用户）或密码为空，改密后可能因 host 匹配逻辑变化导致登录路径改变。例如：
- 存在
''@'localhost'和'u'@'localhost'两个用户，MySQL 会优先匹配空用户名（按 host/user 排序规则），改密后者并不影响前者行为 - 用
mysql -u u -h 127.0.0.1和mysql -u u -h localhost可能命中不同账户（前者走 TCP，后者走 socket，host 匹配不同）
这类情况建议先查清实际匹配的账户：SELECT user,host,plugin,authentication_string FROM mysql.user WHERE host LIKE '%localhost%' ORDER BY host,user;
真正麻烦的不是改密本身，而是没意识到 MySQL 认证是「插件 + 密码 + host/user 组合」三者共同决定的，缺一不可。
