mysql本身不提供密码解密功能，因其用户密码采用单向哈希（如sha256或caching_sha2_password）存储，不可逆；应用层须用bcrypt等专用库加盐哈希并比对，禁用password()、md5()、sha1()等弱函数。
直接说结论：MySQL 本身不负责密码加密逻辑，只提供哈希函数；真正安全的密码存储必须在应用层完成加盐 + 慢哈希（如 bcrypt），且盐值不能全局固定、不能写死在 SQL 里。
为什么不能用 MD5() 或 SHA2() 直接存密码
MySQL 的 MD5() 和 SHA2() 是纯哈希函数，无抗暴力能力。它们执行快、无内置加盐机制，且无法抵御彩虹表或 GPU 碰撞攻击。即使你手动拼接盐值（如 SHA2(CONCAT('abc123', ?), 256)），问题仍存在：
- 盐值是全局固定的，相同密码在所有用户中生成相同密文
- 数据库一旦被拖库，攻击者可批量预计算常见密码+固定盐的 SHA256 值
-
SHA2()是通用哈希，不是为密码设计的慢哈希，每秒可尝试上亿次 - MySQL 不支持 bcrypt、scrypt、Argon2 等现代密码哈希算法
应用层加盐 bcrypt 才是生产唯一可行方案
把密码哈希逻辑移出 MySQL，交给后端语言处理。以 Python（bcrypt）和 Java（Spring Security Crypto）为例：
- 注册时：生成随机盐（
bcrypt.gensalt(rounds=12)），再用该盐哈希密码，把完整哈希字符串（含盐、轮数、结果）存入 MySQL 的password字段（VARCHAR(255)） - 登录时：查出该用户的哈希串，用
bcrypt.checkpw(输入密码, 存储的哈希串)验证——全程不拼接、不重算盐 - 字段设计：
password VARCHAR(255) NOT NULL，别再用VARCHAR(64)适配 SHA256，那是过时做法 - 绝对不要在 SQL 里调用任何哈希函数做校验，比如
WHERE password = SHA2(...)—— 这等于把哈希逻辑暴露给数据库权限模型，且无法使用 bcrypt
~/.mylogin.cnf 和 mysql_config_editor 只管客户端连接密码
这两个工具解决的是「应用连接 MySQL 数据库时的认证凭据」问题，和「用户表里存的密码」完全无关：
-
mysql_config_editor加密保存的是root或应用账号（如app_rw）连数据库的密码，用于mysql -u app_rw -p自动登录 - 它不影响你业务表中
user.password字段怎么存、怎么校验 - 如果你把用户密码硬编码进
~/.mylogin.cnf，那反而彻底混淆了「系统账号」和「业务账号」两个安全域 - 该文件权限必须是
chmod 600 ~/.mylogin.cnf，否则 MySQL 客户端会拒绝读取
最容易被忽略的三个实操细节
很多团队在迁移 bcrypt 后仍出问题，往往卡在这三点：
- 前端传来的密码没 trim()，导致空格被当成密码一部分；后端必须
password.strip()再哈希 - 数据库字段用了
CHAR或带utf8mb4_bin以外的 collation，导致 bcrypt 哈希串里的$、/被截断或转义 - 开发环境用明文密码调试时，日志里打印了原始密码或哈希串——必须全局 grep
password、pwd、passwd，禁用所有相关 log 输出
