MySQL 8.0 用 ALTER USER 修改密码最稳妥
MySQL 8.0+ 已彻底移除 SET PASSWORD ... = PASSWORD('xxx') 这类语法，强行用会报错 ERROR 1064 (42000)。官方只保留 ALTER USER 作为标准方式，且必须显式指定认证插件（尤其是从老版本升级上来的实例）。
常见错误现象：执行 SET PASSWORD FOR 'u'@'%' = '123' 直接失败；或改完密码后用户连不上，提示 Access denied for user —— 很可能是因为没指定插件，MySQL 默认用了 caching_sha2_password，但客户端不支持。
- 必须写全用户名和 host：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'newpass'; - 如果不确定当前插件，先查：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'your_user'; - 想兼容旧客户端（如某些 PHP MySQL 扩展），优先选
mysql_native_password；新部署建议用caching_sha2_password（更安全）
MySQL 5.7 仍可用 SET PASSWORD，但有陷阱
SET PASSWORD 在 5.7 是合法的，但它的行为容易被误解：它**不校验旧密码**，也不检查密码策略，且对 root 用户在某些配置下会静默失败（比如启用了 skip-grant-tables 后又忘了 flush）。
使用场景：快速重置一个已知账户、无密码策略限制的测试库；线上生产环境不推荐。
- 正确写法是：
SET PASSWORD FOR 'u'@'%' = PASSWORD('newpass');（注意PASSWORD()函数必须小写，大写会报错） - 改完必须执行：
FLUSH PRIVILEGES;，否则改动不生效 - 如果启用了 validate_password 插件，
PASSWORD()生成的哈希值可能被拒绝——这时得先临时关掉：SET GLOBAL validate_password.policy = LOW;
忘记 root 密码时，跳过权限验证修改的实操要点
不是所有“跳过验证”都能直接改密码。MySQL 8.0 和 5.7 的启动参数、初始化逻辑不同，硬加 --skip-grant-tables 可能导致 mysql.user 表不可写，或者 ALTER USER 报错 ERROR 1290 (HY000)。
关键区别在于：8.0 要求先用 --init-file 执行 SQL 初始化密码，而 5.7 可以进库后直接更新 mysql.user 表（但字段名变了，5.7 是 authentication_string，不是 Password）。
- MySQL 8.0 推荐做法：停库 → 创建 init.sql（内容为
ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpass';）→ 启动时加--init-file=/path/to/init.sql→ 启动成功后删掉该文件 - MySQL 5.7 可进库后执行：
UPDATE mysql.user SET authentication_string = PASSWORD('newpass') WHERE User = 'root'; FLUSH PRIVILEGES; - 无论哪个版本，改完都要确认
plugin字段值是否匹配，否则登录时认证失败
客户端连接失败？重点检查 plugin 和 SSL 配置
密码改成功了，但应用连不上，90% 是因为 plugin 和客户端能力不匹配，剩下 10% 是 SSL 强制要求没满足（尤其云数据库）。
典型现象：命令行 mysql -u u -p 能登，但 Python 的 pymysql 或 Node.js 的 mysql2 报 Authentication plugin 'caching_sha2_password' cannot be loaded。
- 查用户插件：
SELECT plugin FROM mysql.user WHERE User='u' AND Host='%'; - 临时切回兼容插件：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pass'; - 如果服务端强制 SSL（如阿里云 RDS），客户端连接字符串里必须带
?ssl=true或对应配置，光改密码没用
plugin 字段和 SSL 策略才是真正在背后卡人的地方。别只盯着密码值本身。 
