MySQL存储过程不能实现SHA2算法，因其是依赖OpenSSL的内核级函数，SQL/PSL缺乏位运算等必要能力；只能调用内置SHA2()函数，且第二参数必须为224/256/384/512，输入NULL时返回NULL，输出为固定长度十六进制字符串，不可逆。
MySQL 存储过程中不能“实现”MD5 或 SHA2 算法，只能直接调用内置函数 MD5() 和 SHA2() —— 它们是原生 C 实现的不可替换函数，不支持用户自定义逻辑替代。
为什么不能在存储过程中“实现”SHA2
SHA2 是 MySQL 内核级函数，依赖 OpenSSL 底层实现；存储过程语法（SQL/PSL）没有位运算、循环移位、常量表等能力，无法复现 SHA-256 的 64 轮压缩函数。试图用循环+字符串拼接模拟只会得到错误结果，且性能极差。
常见错误现象：SELECT SHA2('abc', 256) 返回 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad，而自己写的“模拟函数”几乎必然不一致。
- SHA2 的第二参数必须是
224、256、384或512—— 其他值如2560或'256'（字符串）会导致返回NULL -
MD5()无参数，固定输出 32 字符十六进制；SHA2()输出长度随 bit 数变化：SHA2(..., 256)是 64 字符，SHA2(..., 512)是 128 字符 - 输入为
NULL时，两者都返回NULL，不是空字符串
存储过程里怎么安全调用 SHA2
直接用 SHA2() 没问题，但要注意盐值（salt）必须在应用层生成并传入，或由存储过程生成随机 salt —— MySQL 本身没有安全随机数生成器，RAND() 不适合做 salt。
- 推荐方式：应用层生成 16 字节 salt（如 UUID 或加密安全随机字节），传入
IN p_salt CHAR(32)（HEX 形式），再在过程内拼接：SHA2(CONCAT(p_salt, p_password), 256) - 避免硬编码 salt：
SET @salt = 'fixed_salt_123';—— 所有用户哈希可被批量彩虹表破解 - 字段类型要匹配：存
SHA2(..., 256)结果请用CHAR(64)，不是VARCHAR(255)（浪费空间且易误判）
别把 SHA2 当加密，更别尝试“解密”
SHA2() 和 MD5() 是单向哈希，不是加密函数。不存在 UNSHA2() 或任何逆向函数 —— 这是设计使然，不是 MySQL 缺失功能。
- 错误操作：
SELECT * FROM users WHERE password_hash = SHA2('input', 256);—— 表面可行，但若没加 salt，撞库秒破 - 真正需要可逆加解密，请用
AES_ENCRYPT()/AES_DECRYPT()，但必须显式指定模式和 IV，且密钥长度严格为 16/24/32 字节 - 如果只是校验密码，永远用
WHERE username = ? AND password_hash = SHA2(?, 256)，不要在应用层先算哈希再比对（除非你控制所有字符集转换）
最常被忽略的一点：MySQL 默认字符集（如 utf8mb4）会影响哈希输入。比如 SHA2('café', 256) 在连接字符集为 latin1 时实际哈希的是 café 的 latin1 编码字节，而非 UTF-8 字节 —— 结果完全不同。务必统一客户端、连接、表字段的字符集，并在测试时用 HEX('café') 确认输入字节流。
