mysql 8.0 彻底删除 password() 等加密函数，因其实现为无 salt、无迭代的双 sha-1，极易被彩虹表破解；同时移除 encode()/decode()、encrypt()、des_encrypt()/des_decrypt() 等不安全或不可移植函数，不再提供 sql 层密码哈希功能，强制密码哈希交由认证插件（如 caching_sha2_password）或应用层安全算法（如 bcrypt）处理。
PASSWORD() 函数在 MySQL 8.0 中不是“被弃用”，而是物理删除——调用它会直接报错 ERROR 1305 (42000): FUNCTION mydb.PASSWORD does not exist。这不是兼容性开关问题，是源码里真没了。
直接删掉 PASSWORD() 是因为太危险
- 它用的是双 SHA-1 哈希：
SHA1(SHA1('pwd'))，无 salt、无迭代、输出固定 40 字符 hex - 输入
'root'永远得到'*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B'，彩虹表秒破 - 和认证流程强耦合，让开发者误以为“用了 PASSWORD 就算加密了”，实际等同明文
其他被删的加密函数也遵循同一逻辑
MySQL 8.0 彻底移除了以下函数（调用即报 ERROR 1305）：
-
ENCODE()/DECODE() -
ENCRYPT() -
DES_ENCRYPT()/DES_DECRYPT()
它们要么依赖系统级 crypt()（不可移植）、要么使用弱算法（DES）、要么缺少密钥管理机制，不符合现代安全基线。
替代方案不是“换一个函数”，而是重构密码处理位置
- 数据库用户密码：必须由服务端插件完成哈希，比如
caching_sha2_password（SHA2-256 + salt + 迭代），应用层不该也不许自己算哈希后写入authentication_string字段 - 应用自定义用户表：可用
SHA2('pwd', 256)，但要清楚它无 salt；若需真正安全，应改用应用层 bcrypt/scrypt/PBKDF2 实现 - 绝对不要用
MD5()或裸SHA1()做密码存储，哪怕只是过渡
真正容易被忽略的点是：MySQL 8.0 不再提供任何“SQL 层密码哈希函数”作为通用替代品。它把责任明确交还给应用层或认证插件——这既是安全升级，也是边界厘清。
