在MySQL中处理历史数据的清洗任务时，我们经常遇到需要根据某种模式来改写字段内容的场景，例如把表中所有邮箱域名从旧后缀改成新后缀，或者将杂乱的电话号码格式统一为纯数字。很多初学者第一反应是寻找一个能直接写正则的替换命令，但MySQL的SQL语法体系里并没有提供类似其他语言中“正则替换”那样的一站式函数。理解这一点，是设计正确更新方案的前提。
MySQL原生正则能力边界与替代思路
MySQL提供了REGEXP和RLIKE操作符，它们只能用于WHERE条件中判断某列是否匹配指定模式，并不能在SELECT或UPDATE中直接完成“按正则捕获并改写”的动作。与之对应的是REPLACE()函数，它仅仅执行字面量的子串替换，完全不解析正则表达式。因此，当你写REPLACE(content, '[0-9]+', 'X')时，数据库会真的去找名为“[0-9]+”的文本，而不是把数字替换掉。
要在不引入外部工具的情况下实现“类正则替换”，常见的做法是分两步：先用REGEXP筛选出需要改动的行，再通过组合SUBSTRING、LOCATE、INSERT等字符串函数，针对已知结构的文本做定点改写。例如，若某字段总是“姓名-旧域名”的形式，可以用LOCATE('-', col)找到分隔位置，再拼装新字符串。这种方式虽不能应对任意复杂正则，但在格式相对固定的业务数据上非常稳妥，且完全跑在数据库内，不依赖导出导入。
下面示例展示如何把“user@old.com”形式的邮箱改为“user@ipipp.com”，假设旧域名固定为old.com：
UPDATE user_table
SET email = CONCAT(
SUBSTRING(email, 1, LOCATE('@old.com', email) - 1),
'@ipipp.com'
)
WHERE email REGEXP '@old\.com$';
上述语句中，LOCATE找到“@old.com”的起始位置，SUBSTRING截取用户名部分，最后用CONCAT拼接新域名。注意正则里点号需要转义为\.，因为MySQL字符串里反斜杠本身也要转义。这种写法比全量导出再用脚本处理要轻量，但对不规则文本仍显笨拙。
借助用户自定义函数扩展正则替换
如果业务里频繁需要做灵活的正则替换，更好的方案是在MySQL中创建用户自定义函数（UDF），或者利用已有的第三方库如lib_mysqludf_preg。这类扩展把PCRE正则引擎引入数据库，提供类似PREG_REPLACE的函数，让你能写UPDATE t SET col = PREG_REPLACE('/[0-9]/', 'X', col)。它的优势是表达力强，一条语句就能解决复杂模式，但缺点是需要数据库服务器安装共享库，并且运维权限较高，在云数据库或受管实例上往往不可行。
不依赖外部库时，也可以用存储过程加循环来模拟。思路是：声明游标遍历命中REGEXP的行，在过程内用一系列IF分支和字符串函数逐步改写。虽然代码量大，但兼容性好，任何MySQL环境都能跑。下面的简版存储过程演示了如何把连续数字替换成井号，仅作结构参考：
DELIMITER //
CREATE PROCEDURE mask_digits()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE v_id INT;
DECLARE v_text TEXT;
DECLARE cur CURSOR FOR SELECT id, info FROM logs WHERE info REGEXP '[0-9]';
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur;
read_loop: LOOP
FETCH cur INTO v_id, v_text;
IF done THEN LEAVE read_loop; END IF;
WHILE v_text REGEXP '[0-9]' DO
SET v_text = INSERT(v_text, LOCATE(SUBSTRING(v_text, LOCATE('0', v_text)), v_text), 1, '#');
-- 仅示意，真实场景需更严谨定位数字起点
END WHILE;
UPDATE logs SET info = v_text WHERE id = v_id;
END LOOP;
CLOSE cur;
END //
DELIMITER ;
这个例子刻意写得简单，实际中应使用更准确的位置计算来避免死循环。它说明了在不支持原生正则替换时，用过程化逻辑弥补的可行性。比起单条SQL，存储过程更灵活，也能在每次迭代中控制提交节奏，降低长事务风险。
批量更新时的性能与安全措施
无论采用哪种替换方式，对生产表直接UPDATE都可能引发锁表、主从延迟和二进制日志暴涨。建议先在小范围用SELECT ... REGEXP评估命中行数，再决定分批策略。例如按主键区间每次更新一千行，并在应用层睡眠片刻，可显著减轻从库压力。同时，操作前务必用CREATE TABLE backup_xxx SELECT * FROM target WHERE ...留存快照，防止正则写错导致数据无法回滚。
另一个容易被忽视的点是字符集。正则匹配依赖列的排序规则，若字段是utf8mb4而正则里写了非ASCII范围，可能匹配行为和预期不同。执行前可用SHOW FULL COLUMNS FROM table确认，必要时在正则前用CONVERT(col USING utf8mb4)显式统一。对于超大型表，还可以考虑把待替换数据导到临时表，在临时表上完成正则逻辑后再RENAME TABLE切换，从而把线上写锁压缩到秒级。
最后，若环境允许，把数据用SELECT ... INTO OUTFILE导出，交给支持正则的脚本语言处理，再LOAD DATA回去，往往是开发效率最高的路径。它把正则替换的复杂性转移到了成熟的文本处理工具上，数据库只负责搬运。选择哪种方案，核心取决于你对线上稳定性、运维权限和开发速度的综合权衡。