MySQL 8.0 彻底物理删除了 PASSWORD() 函数，调用即报 ERROR 1305，因其源码中已移除全部实现；它不安全（无 salt 双 SHA-1），且被插件化认证（如 caching_sha2_password）取代，密码哈希必须由服务端自动完成。
MySQL 8.0 中 PASSWORD() 函数已被物理删除，调用即报 ERROR 1305 (42000): FUNCTION db.PASSWORD does not exist —— 它不是“不推荐”，而是彻底没了。
为什么直接调用 PASSWORD() 会语法报错
MySQL 8.0 的源码里删掉了这个函数的全部实现，包括解析器入口、执行逻辑和文档条目。SQL 解析阶段遇到 PASSWORD('xxx') 就会失败，错误位置通常在 near 'PASSWORD('。这不是配置问题，也不是权限问题，是二进制层面不存在。
- MySQL 5.7 还能用，但手册已标为
deprecated；8.0.0 起完全移除 - 哪怕你用
--skip-grant-tables启动，或手动 patch 旧版代码，也无法恢复该函数 - 错误不是运行时报“哈希失败”，而是解析时报“函数不存在”——说明它连被调用的机会都没有
别用 SHA1() 或 MD5() 直接替代 PASSWORD()
网上很多教程建议用 SHA1() 或 MD5() “顶替”，这是危险误导：这些函数输出的是裸哈希值，而 MySQL 8.0 的认证插件（如 caching_sha2_password）需要特定二进制格式的 salted + iterated 哈希，不是字符串拼接能模拟的。
-
SELECT SHA1('abc')返回 40 字符十六进制，而caching_sha2_password存储的是 base64 编码的 32 字节 salted SHA2-256 + 元数据 - 把
SHA1()结果写进mysql.user.authentication_string字段，用户将无法登录 —— 插件校验时直接跳过或报Access denied - 应用层自行哈希再存库，等于绕过 MySQL 认证体系，丧失插件提供的握手优化、缓存验证、密码策略等能力
正确做法：交由 MySQL 服务端自动处理密码哈希
MySQL 8.0 的设计原则是“密码哈希必须由认证插件完成”，应用层不该、也不能干预哈希过程。所有密码设置必须走声明式语句，让服务端按当前默认插件生成合规哈希值。
- 创建用户：
CREATE USER 'u'@'localhost' IDENTIFIED BY 'p@ssw0rd'; - 修改密码：
ALTER USER 'u'@'localhost' IDENTIFIED BY 'new_p@ss'; - 若需指定插件（例如兼容老客户端），显式加
USING：ALTER USER 'u'@'localhost' IDENTIFIED WITH mysql_native_password BY 'p@ss'; - 绝对不要手写
UPDATE mysql.user SET authentication_string = ...—— 这会破坏插件状态，后续FLUSH PRIVILEGES也不一定能修复
如果你真要自己算哈希（比如迁移旧系统）
极少数场景下（如从 MySQL 5.7 批量导入用户到 8.0），你可能需要预生成插件兼容的哈希值。这时不能靠 SQL 函数，得用对应插件的参考实现：
-
caching_sha2_password：需用 OpenSSL 或 Python 的hashlib.pbkdf2_hmac('sha256', pwd, salt, 5000)再加固定前缀和编码，细节见 MySQL 源码sql/auth/caching_sha2_password.cc -
mysql_native_password：仍是 salted SHA1，但 salt 是随机生成的 20 字节，且格式为*<40-char-sha1>，不能直接用SHA1()替代 - 最稳妥方式：在临时 5.7 实例中执行
SELECT PASSWORD('xxx');，再用CREATE USER ... IDENTIFIED WITH mysql_native_password AS '...';导入 8.0
真正容易被忽略的点是：MySQL 8.0 的密码安全不是“换一个哈希函数”的事，而是整个认证流程下沉到插件层。任何试图在 SQL 层用函数“模拟”密码哈希的操作，本质上都在对抗设计意图。
