mysql 8.0 彻底移除了 password() 函数，调用即报 error 1305，因其源码中已物理删除；该函数采用无 salt 双 sha-1 哈希，极不安全；官方不再提供 sql 层密码哈希替代方案，而是升级为插件化认证（如 caching_sha2_password），要求应用层自行处理密码哈希。
MySQL 8.0 直接移除了 PASSWORD() 函数，不是“弃用”，而是彻底删除 —— 调用它会报错 ERROR 1305 (42000): FUNCTION mydb.PASSWORD does not exist。
为什么调用 PASSWORD() 会报错
因为 MySQL 8.0 的源码里已经删掉了这个函数的实现。它不是被隐藏或禁用，而是像删除一个不存在的 C 函数一样，从服务器二进制中物理移除。任何 SQL 中出现 PASSWORD('xxx') 都会在语法解析阶段失败，错误位置通常在 near 'PASSWORD(...'。
- MySQL 5.7 还保留该函数，但官方文档已标为 deprecated（不推荐使用）
- MySQL 8.0.0 起完全移除，包括函数定义、手册条目、测试用例
- 即使你手动编译旧版 patch 或用兼容模式启动，也无法恢复该函数
PASSWORD() 本身有多不安全
它用的是双 SHA-1 哈希（SHA1(SHA1(password))），且无 salt、无迭代、输出固定长度（40 字符十六进制），极易被彩虹表和 GPU 暴力破解。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
- 输入
'root'总是得到*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B，毫无随机性 - 不支持密钥派生（如 PBKDF2、bcrypt、scrypt），无法抵抗现代哈希算力
- 与 MySQL 用户认证流程强耦合，导致应用层误以为“加密了就安全”，实则形同明文
MySQL 8.0 实际用什么替代密码存储
不是用某个新函数“替代 PASSWORD()”，而是整个认证模型升级：密码哈希由服务端插件完成，应用层不该也不需参与哈希计算。
- 默认插件是
caching_sha2_password：使用 SHA2-256 + salt + 多轮迭代，支持快速缓存验证 - 兼容插件
mysql_native_password：仍用 SHA1 哈希，但加 salt 和 client-side handshake 协商，比PASSWORD()强得多 - 用户创建/修改必须走
CREATE USER ... IDENTIFIED BY或ALTER USER ... IDENTIFIED BY，服务端自动选插件并哈希 - 直接写
authentication_string字段（比如用SHA2('xxx', 256)）是错的 —— 插件需要特定二进制格式，不是裸哈希值
如果必须在 SQL 里做密码哈希（比如插入自定义用户表）
那就别碰 MySQL 内置认证体系，明确区分“数据库用户”和“应用用户”。此时可用标准加密函数，但要注意语义差异：
-
SHA2('pwd', 256)：输出 64 字符 hex，无 salt，适合简单校验，但不抗碰撞 -
MD5('pwd')或SHA1('pwd')：更弱，仅限遗留兼容，不建议新项目使用 - 真正安全的做法是应用层用
password_hash()（PHP）、bcrypt.hash()（Python）等生成带 salt 的哈希，再存入字段 - 切勿在 SQL 里拼接 salt 或模拟 bcrypt —— MySQL 不提供此类原生函数，强行模拟易出错且不可移植
最常被忽略的一点：PASSWORD() 的消失不是孤立事件，它标志着 MySQL 彻底放弃“让用户自己管理密码哈希”的思路。一旦你还在 SQL 里调用哈希函数存密码，说明你还没跳出旧模型 —— 真正的迁移不是找替代函数，而是把密码处理逻辑移出 SQL 层。
