mysql 5.6.17+ 原生支持 to_base64() 和 from_base64()，低版本需自定义函数；创建时须声明 deterministic，推荐封装原生函数以处理换行和字符集，避免全表扫描应优先在应用层解码或使用生成列索引。
MySQL 5.6.17+ 原生支持 TO_BASE64() 和 FROM_BASE64()，但如果你用的是更早版本（如 5.5 或部分 5.6 早期小版本），或需要封装逻辑、统一处理换行/字符集，就得靠自定义函数。直接创建函数是可行的，但必须注意：MySQL 不允许在函数里调用非确定性函数（如 NOW()），且自定义函数不能直接操作表——这两点常导致创建失败。
为什么原生函数不可用时才需自定义？
低版本 MySQL（如 5.5）压根没有 TO_BASE64 和 FROM_BASE64，调用会报错 FUNCTION TO_BASE64 does not exist。而 5.6.17 是第一个引入这两个函数的版本，但部分发行版（如某些 Percona 分支）可能延迟支持。验证方式很简单：
SELECT VERSION();<br>SELECT TO_BASE64('test');
若第二条报错，就确认需自定义。别试图用存储过程替代函数——函数能直接嵌入 SELECT 和 WHERE，过程不能。
创建自定义 Base64 函数的关键限制
MySQL 自定义函数要求 DETERMINISTIC（确定性）、READS SQL DATA（若查表）或 NO SQL（推荐）。Base64 编解码纯计算，应设为 DETERMINISTIC。常见坑包括：
- 未声明
DETERMINISTIC→ 报错This function has none of DETERMINISTIC... - 函数体用了
SELECT ... INTO查表 → 必须加READS SQL DATA，否则拒绝创建 - 参数类型写成
VARCHAR(255)→ 实际传入长文本会截断；建议用TEXT或MEDIUMTEXT - 返回类型设为
VARCHAR却返回二进制结果 → 中文解码后仍是乱码，应返回TEXT并在调用时手动CONVERT(... USING utf8mb4)
如何安全实现 tobase64() 和 frombase64() 函数？
不推荐手写 Base64 查表逻辑（如建 64 行映射表再拼接），性能差、易出错。更稳妥的做法是：只在 MySQL 支持原生函数的前提下，用自定义函数做“增强封装”。例如：
编码函数加自动去换行：
DELIMITER $$<br>CREATE FUNCTION tobase64(str TEXT) RETURNS TEXT<br>DETERMINISTIC<br>BEGIN<br> RETURN REPLACE(TO_BASE64(str), '\n', '');<br>END$$<br>DELIMITER ;
解码函数强制转 UTF-8 字符串：
DELIMITER $$<br>CREATE FUNCTION frombase64(encoded_str TEXT) RETURNS TEXT<br>DETERMINISTIC<br>BEGIN<br> RETURN CONVERT(FROM_BASE64(encoded_str) USING utf8mb4);<br>END$$<br>DELIMITER ;
这样既复用原生函数的可靠性，又规避了换行和字符集两大痛点。若真无原生函数，只能引入外部 UDF（如 lib_mysqludf_base64），但部署成本高、权限受限多，生产环境慎用。
WHERE 条件中调用自定义 Base64 函数的陷阱
别写 WHERE name = frombase64('xxx')——即使你封装了 CONVERT，MySQL 优化器仍可能无法利用索引，导致全表扫描。更糟的是，如果 frombase64() 返回 NULL（比如输入非法），整个条件恒假。实操建议：
- 优先把解码逻辑移到应用层，数据库只存原始值或预计算字段
- 若必须在库内解码查，先过滤长度：
WHERE LENGTH(encoded_col) % 4 = 0 AND encoded_col NOT REGEXP '[^A-Za-z0-9+/=]' - 对高频查询字段，增加一个生成列：
ALTER TABLE t ADD decoded_name TEXT AS (CONVERT(FROM_BASE64(encoded_col) USING utf8mb4)) STORED，然后给该列建索引
自定义函数不是银弹。它掩盖不了底层字符集混乱、连接层配置错误、或原始数据已损坏的问题——这些得从源头 fix，而不是靠函数兜底。
