MySQL 8.0 已物理删除 PASSWORD() 函数，调用即报 ERROR 1305；不可用 SHA1() 或 MD5() 替代，因其输出裸哈希，而 caching_sha2_password 插件要求带 salt 和迭代的二进制哈希，必须通过 CREATE USER 或 ALTER USER 由服务端自动处理。
MySQL 8.0 中 PASSWORD() 函数已物理删除，任何调用都会直接报错 ERROR 1305 (42000): FUNCTION db.PASSWORD does not exist —— 不是“不推荐”，是根本不存在。
为什么不能用 SHA1() 或 MD5() 替代 PASSWORD()
很多人看到报错后随手改成 SHA1('pwd') 或 MD5('pwd')，结果用户死活登不上。这是因为：
-
caching_sha2_password插件需要的是带 salt、多轮迭代的二进制哈希值，不是裸字符串哈希 -
SHA1('root')返回固定 40 字符十六进制串，而插件校验时会跳过该字段或直接拒绝认证 - 手动写入
authentication_string字段等于绕过整个认证体系，后续FLUSH PRIVILEGES也无法修复状态 - 即使你用
--skip-grant-tables启动，也改不了函数被源码删除的事实
正确修改密码必须走声明式语句
所有密码操作必须交由 MySQL 服务端按当前认证插件自动哈希，不能干预过程：
- 新建用户：
CREATE USER 'u'@'localhost' IDENTIFIED BY 'p@ssw0rd'; - 修改密码：
ALTER USER 'u'@'localhost' IDENTIFIED BY 'new_p@ss'; - 强制指定旧插件（仅限兼容老客户端）：
ALTER USER 'u'@'localhost' IDENTIFIED WITH mysql_native_password BY 'p@ss'; - 绝对不要：
UPDATE mysql.user SET authentication_string = ...或SET PASSWORD = PASSWORD('x');
导出用户信息时如何避免泄露 authentication_string
导出 mysql.user 表做审计或迁移时，authentication_string 必须显式排除：
- 错误写法：
SELECT * FROM mysql.user INTO OUTFILE '/tmp/users.csv';—— 会包含敏感哈希值 - 正确写法：
SELECT user, host, plugin, account_locked, password_expired FROM mysql.user; - 注意：
plugin字段可保留，用于判断认证方式；但authentication_string和残留的password字段都不可导出 - 该语句需执行者拥有
FILE权限，且目标路径由 MySQL 进程可写（不是你本地终端）
最容易被忽略的一点：MySQL 8.0 没有提供任何 SQL 层密码哈希函数作为替代品。它把责任明确划清——数据库只管用插件安全认证，哈希这件事不该、也不能由 SQL 语句来干。
