mysql 8.0 彻底物理删除 password() 函数而非弃用，因其采用无 salt、无迭代的双 sha-1 哈希，极易被彩虹表破解，且源码中已移除全部实现；密码哈希必须由服务端认证插件（如 caching_sha2_password）完成，应用层不可干预。
MySQL 8.0 中的 PASSWORD() 函数不是“被替换”，而是物理删除——调用它会直接报错 ERROR 1305 (42000): FUNCTION db.PASSWORD does not exist，连解析都过不去。
为什么 PASSWORD() 被彻底删掉而不是弃用？
它用的是双 SHA-1 哈希：SHA1(SHA1('pwd'))，无 salt、无迭代、输出固定 40 字符 hex。输入 'root' 永远得到 '*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B'，彩虹表一查就中。更危险的是，它长期被误用为“密码加密”，实际等同明文存储。
这不是算法升级问题，是安全基线失效：MySQL 8.0 把密码哈希这件事从 SQL 层彻底剥离，交由认证插件（如 caching_sha2_password）在服务端完成，不允许应用层干预。
- 源码里真没了——包括函数定义、解析器入口、测试用例、文档条目
- 哪怕用
--skip-grant-tables启动，或手动 patch 旧版代码，也无法恢复 - 错误不是运行时报“验证失败”，而是 SQL 解析阶段就报“函数不存在”
MD5()、SHA1()、SHA2() 能当 PASSWORD() 的替代品吗？
能“用”，但不能“当替代品”——语义完全不同。
MD5('123') 返回 32 字符 hex，SHA2('123', 256) 返回 64 字符 hex，它们只是普通哈希函数，不带 salt、不支持迭代、不生成插件可识别的二进制格式。把它们的结果写进 mysql.user.authentication_string 字段，用户将无法登录。
- 这些函数只适合应用自定义用户表（比如
users.password字段），且仅限简单校验场景 - 若用于真实密码存储，必须配合应用层 salt（如 PHP 的
password_hash()、Python 的bcrypt.hashpw()） - 绝对不要在 SQL 里拼接 salt 或模拟 bcrypt——MySQL 不提供原生支持，强行模拟不可移植且易出错
真正该怎么做：区分“数据库用户”和“应用用户”
这是最容易被忽略的边界问题。MySQL 8.0 明确要求：数据库用户的密码哈希必须由服务端插件完成，应用层无权也不应参与。
- 创建/修改数据库用户，必须用
CREATE USER 'u'@'h' IDENTIFIED BY 'p'或ALTER USER ... IDENTIFIED BY - 需要指定插件时，显式写
IDENTIFIED WITH caching_sha2_password BY 'p'，而非手写哈希值 - 绝不要
UPDATE mysql.user SET authentication_string = ...—— 这会破坏插件状态，后续FLUSH PRIVILEGES都可能无法修复 - 如果你的应用有自己的一套用户表（
users），那就完全绕开 MySQL 认证体系，用应用层 bcrypt/scrypt/PBKDF2 处理，SQL 层只存哈希结果
关键点在于：MySQL 8.0 不再提供任何“SQL 层密码哈希函数”作为通用替代品。它把责任明确交还给应用层或认证插件——这不是功能缩水，而是边界厘清。混淆这两者，是绝大多数迁移失败的根源。
