MySQL 8.0+才支持REGEXP_REPLACE，5.7及更早版本不支持；pattern必须为常量、兼容collation、避免动态拼接，且仅限POSIX ERE语法。
MySQL 8.0+ 才能用 REGEXP_REPLACE，低版本直接报错
自定义函数里调用正则替换，前提是 MySQL 版本 ≥ 8.0。5.7 或更早版本没有 REGEXP_REPLACE 函数，写进去会报 FUNCTION xxx.REGEXP_REPLACE does not exist。别在测试环境用 8.0、生产用 5.7 —— 这种混用最容易漏掉兼容性检查。
自定义函数中不能直接声明 REGEXP_REPLACE 的参数为可变长度模式
REGEXP_REPLACE 的第二个参数（正则 pattern）必须是常量字符串或确定值，不能是拼接表达式（比如 CONCAT('(', @prefix, ')')），否则会报 Invalid regular expression 或在运行时失败。常见踩坑点：
- 传入的 pattern 字符串含未转义的
（如想匹配反斜杠，得写成'\\'） - pattern 中用了 MySQL 不支持的语法（比如
d、s、\K、lookbehind）—— MySQL 只支持 POSIX ERE 风格，不支持 PCRE - 在函数体里用变量拼接 pattern，例如
SET @pat = CONCAT('[', in_charset, ']');再传给REGEXP_REPLACE(str, @pat, ...)，这在存储函数中是非法的，会触发 SQL 错误
想复用复杂正则逻辑？优先用函数封装固定 pattern，而非动态生成
如果你需要“把邮箱域名统一换为 example.com”“把手机号中间四位脱敏为 ****”这类固定规则，就直接在函数里硬编码 pattern，别试图让函数接受 pattern 作为参数。示例：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
DELIMITER $$
CREATE FUNCTION clean_email_domain(input_email TEXT)
RETURNS TEXT
READS SQL DATA
DETERMINISTIC
BEGIN
IF input_email IS NULL THEN
RETURN NULL;
END IF;
RETURN REGEXP_REPLACE(input_email, '@[^@\s]+$', '@example.com');
END$$
DELIMITER ;
这样调用安全：SELECT clean_email_domain('user@old.com');。一旦你改成接收 in_pattern 参数并拼进 REGEXP_REPLACE，函数就不可预测了。
性能和字符集容易被忽略：pattern 和输入文本的 collation 必须兼容
REGEXP_REPLACE 返回结果的字符集和排序规则（collation）继承自第一个参数（expr）。如果字段是 utf8mb4_0900_as_cs，但你在函数里传入一个 latin1 字符串字面量做 pattern，可能触发隐式转换失败或匹配异常。最稳妥的做法：
- 所有字符串参数显式加
COLLATE utf8mb4_0900_as_cs（按你表实际 collation 调整） - 避免在函数里处理超长文本（> 1MB），
REGEXP_REPLACE在大文本上性能下降明显，且可能触发max_allowed_packet限制 - 函数标记为
DETERMINISTIC仅当 pattern 和 replace 确实恒定；若含 NOW()、RAND() 等非确定性内容，必须用NO SQL或CONTAINS SQL，否则创建失败
真正麻烦的不是写法，而是 pattern 的边界情况——比如想删 HTML 标签，'<.>'</.> 会贪婪匹配到第一个 > 之后的所有内容，跨标签失效；换成 ']*>' 才靠谱。这种细节，不跑真实数据根本看不出来。
