ERROR 1045(28000)是权限不足导致，需root或具备ALTER USER/UPDATE mysql.user权限的高权限账户执行；MySQL 8.0+必须用ALTER USER 'u'@'h' IDENTIFIED BY 'p'语法并注意认证插件兼容性。
ALTER USER 修改密码时提示 ERROR 1045 (28000)
这是权限不足的典型表现，ALTER USER 不是普通用户能执行的操作。必须用具有 mysql.session 权限或 UPDATE 权限在 mysql.user 表上的高权限账户（如 root）登录后执行。
常见错误现象：用刚创建的普通用户自己改自己密码，或者用低权限运维账号尝试修改他人凭证。
- 确认当前登录账户是否为
root@localhost或拥有CREATE USER、ALTER USER权限 - 如果使用远程连接，检查
root是否允许从该 host 登录（比如root@'%'而非仅root@localhost） - MySQL 8.0+ 默认启用
caching_sha2_password插件，旧客户端可能不兼容，导致连上就报错——先确保连接本身稳定再操作密码
ALTER USER 语法差异：MySQL 5.7 vs 8.0+
MySQL 8.0 彻底弃用了 SET PASSWORD 和直接 UPDATE mysql.user 的方式，ALTER USER 成为唯一推荐路径；但参数写法有关键变化。
最常踩的坑是照搬老文档写 IDENTIFIED BY 'xxx' 却漏掉 FOR 子句，或混淆了用户名格式。
- 正确写法（MySQL 8.0+）：
ALTER USER 'username'@'host' IDENTIFIED BY 'newpass'; - 错误写法：
ALTER USER 'username' IDENTIFIED BY 'newpass';（缺少@'host'，会默认匹配@'%'，可能改错账户） - MySQL 5.7 支持但不推荐：
SET PASSWORD FOR 'u'@'h' = PASSWORD('p');——PASSWORD()函数已在 8.0 移除 - 密码强度策略由
validate_password插件控制，若启用，弱密码会直接报ERROR 1819
修改后无法登录？检查 authentication plugin 是否匹配
MySQL 8.0 默认插件是 caching_sha2_password，而很多老应用（如某些 PHP 版本、旧版 MySQL Workbench）只认 mysql_native_password。改完密码却登不上，八成是这个原因。
不是密码错了，是认证机制不兼容。
- 查看当前用户插件：
SELECT Host,User,plugin FROM mysql.user WHERE User='username'; - 强制指定插件重置（兼顾兼容性）：
ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'p'; - 若需长期用新插件，客户端需升级到支持 SHA-256 认证的版本（如 MySQL Connector/J 8.0.13+、PHP 7.4+）
- 注意：
FLUSH PRIVILEGES在ALTER USER后不需要——该语句自动生效
批量修改或脚本化更新时的陷阱
运维写 Shell/Python 脚本批量重置密码时，容易忽略空格、引号嵌套、特殊字符转义，以及并发执行冲突。
比如密码含 $、'、`，Shell 变量未加单引号包裹，会导致 SQL 解析失败或注入风险。
- 命令行中避免双引号包裹整个 SQL：
mysql -e "ALTER USER 'a'@'b' IDENTIFIED BY '$p';"——$p会被 shell 展开 - 安全做法：用单引号 + 参数占位，或通过 stdin 输入：
echo "ALTER USER 'u'@'h' IDENTIFIED BY 'p';" | mysql -u root -p - 批量操作前先查出目标用户列表：
SELECT CONCAT("ALTER USER '",User,"'@'",Host,"' IDENTIFIED BY 'temp123';") FROM mysql.user WHERE ...;，生成语句再审阅 - 生产环境切忌在无事务上下文里连续执行多个
ALTER USER——它不支持回滚，输错一个就只能手动补救
密码更新本身很简单，难的是搞清你面对的是哪个 MySQL 版本、谁在连、用什么客户端、插件有没有配对。漏掉任意一环，都会卡在“明明改了却登不上”这种问题里。
