MySQL 8.0+ 原生支持 TO_BASE64() 和 FROM_BASE64()，低版本报错；TO_BASE64() 默认每76字符加换行符，需 REPLACE 去除；FROM_BASE64() 返回 VARBINARY，中文解码后须 CONVERT(... USING utf8mb4) 避免乱码。
MySQL 8.0+ 才能直接用 TO_BASE64() 和 FROM_BASE64()，低版本会报 FUNCTION TO_BASE64 does not exist 错误；这两个函数不处理换行、不校验字符集合法性，输错就静默返回 NULL，不是报错。
TO_BASE64() 编码时为什么结果带换行符？
MySQL 的 TO_BASE64() 默认每 76 个字符插入一个 \n（换行符），这是 RFC 4648 兼容行为，但多数业务场景不需要它——比如存进数据库字段、拼 JSON、传给前端或做 WHERE 条件时，换行会导致 FROM_BASE64() 解码失败。
实操建议：
- 编码后立刻用
REPLACE(TO_BASE64(str), '\n', '')去掉换行，尤其用于存储或传输时必须加这步 - 如果字段含中文，确保连接层字符集是
utf8mb4，否则TO_BASE64('你好')可能因隐式转换截断字节 - 不要对已编码过的字符串再套一层
TO_BASE64()，比如TO_BASE64(TO_BASE64('x'))，结果是双重编码，后续无法用单次FROM_BASE64()还原
FROM_BASE64() 解码后返回的是 VARBINARY，不是字符串
FROM_BASE64() 返回类型固定为 VARBINARY，哪怕你解的是纯 ASCII 文本，也不能直接和 VARCHAR 字段用 = 比较——MySQL 会按二进制字节逐位比对，而字符集隐式转换可能失败，导致恒为 FALSE。
实操建议：
- 需要当文本用时，显式转成字符串：
CONVERT(FROM_BASE64('aGVsbG8=') USING utf8mb4) - 在
WHERE子句中解码查数据，别写WHERE col = FROM_BASE64('xxx')，应写成WHERE CONVERT(FROM_BASE64('xxx') USING utf8mb4) = col或更稳妥地：先解码再 CAST - 输入非法（含空格、
=位置错、长度非 4 倍数）时返回NULL，务必检查：WHERE FROM_BASE64(encoded_col) IS NOT NULL
为什么 FROM_BASE64() 对中文解码后显示乱码？
不是函数出错，而是漏了字符集转换。例如 FROM_BASE64('5L2g5aW9') 返回的是 0xE4F6A0E5A199 这样的二进制，若直接 SELECT，客户端按 latin1 解析就会显示乱码；本质是字节没被正确解释为 UTF-8 序列。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 解码后强制指定编码：
SELECT CONVERT(FROM_BASE64('5L2g5aW9') USING utf8mb4) - 避免在应用层靠猜测修复——MySQL 不会在函数里自动“猜”你原始数据是啥编码，它只忠实地还原字节流
- 如果原始数据来自其他系统（如 Java 的
Base64.getEncoder().encodeToString("你好".getBytes(StandardCharsets.UTF_8))），那 MySQL 解码后也必须用utf8mb4转，否则必然乱码
MySQL 5.7 或更低版本怎么替代？
这些版本没有内置 Base64 函数，FROM_BASE64() 从 5.6.1 加入，但 TO_BASE64() 是 5.6.2 才有，且 5.7 缺少对长文本、二进制安全的完整支持。强行用老版本函数容易踩坑。
实操建议：
- 升级到 MySQL 8.0+ 是最省事方案；若不能升，优先把 Base64 处理移到应用层（PHP/Python/Java 都有成熟库）
- 硬要在 SQL 层实现，可用 UDF（用户定义函数），例如 y-ken/mysql-udf-base64，但需编译安装、权限配置，生产环境维护成本高
- 切勿用
HEX()/UNHEX()模拟 Base64——那是十六进制，不是 Base64，两者不可互换
最容易被忽略的一点：Base64 不是加密，只是编码；TO_BASE64() 输出可被任何人无密钥还原。如果字段含敏感信息，仅靠它防不了窥探，得配合 AES 加密或权限控制。
