原生SQL不支持运行时正则替换，REGEXP_REPLACE()才是正解但仅限MySQL 8.0+、PostgreSQL等；SQLite和MySQL 5.7不支持，须在导入前用sed/awk/Python预处理SQL文本。
SQL 脚本里怎么用正则批量脱敏字段值
直接说结论：原生 sql 不支持运行时正则替换敏感数据，replace() 只能做固定字符串替换，regexp_replace() 才是正解——但它只在 mysql 8.0+、postgresql、oracle 等部分数据库中可用，sqlite 和旧版 mysql 完全不认。
所以「导入时自动替换」这事，不能指望 SQL 脚本自己完成，得把正则逻辑前置到导入前的文本处理阶段。
- 常见错误现象：
UPDATE users SET phone = REGEXP_REPLACE(phone, '\d{3}(\d{4})\d{4}', '***$1****')在 MySQL 5.7 上直接报错FUNCTION REGEXP_REPLACE does not exist - 使用场景：导入 CSV/SQL dump 前，对含手机号、身份证、邮箱的字段做掩码（如
138****1234），避免原始敏感数据落地 - 参数差异：MySQL 8.0 的
REGEXP_REPLACE(str, pattern, replace_str, pos, occurrence)中pos默认为 1，occurrence默认为 0（全部替换）；PostgreSQL 则必须显式写flags参数（如'g'）
用 sed / awk / Python 预处理 SQL 文件最稳
比改数据库函数版本更可靠的做法，是在导入前用命令行工具或脚本清洗 SQL 文本。只要 SQL 是 INSERT 语句格式（比如 mysqldump 输出），就能安全匹配并替换字段值。
- 常见错误现象：直接对整个 SQL 文件跑
sed -i 's/1[3-9]d{9}/***-****-****/g'，结果把建表语句里的注释、字段名甚至 SQL 关键字也误伤了 - 正确做法是锚定到 INSERT 行 + 字段位置，例如用 Python 提取
INSERT INTO users (name, phone, email)后面的 VALUES 子句，再针对第 2、3 个字段做正则替换 - 性能影响：10MB 的 SQL 文件，Python
re.sub()处理通常在 200ms 内；sed更快但难处理跨行 VALUES 或嵌套引号 - 推荐小工具逻辑：
python3 -c " import re, sys sql = sys.stdin.read() # 匹配 INSERT ... VALUES (...) 中的电话字段（假设是第3个字段） sql = re.sub(r"(VALUES \([^)]*?,[^)]*?,)['\"]([1-9]\d{10})['\"]", r"\1'***-****-****'", sql) print(sql) " < dump.sql > clean.sql
MySQL LOAD DATA INFILE 怎么边导入边脱敏
如果用 LOAD DATA INFILE 导 CSV，就真能“导入时”处理——靠 SET 子句调用函数，在写入前转换字段值。
- 使用场景：CSV 有原始手机号列，目标表对应字段要存脱敏后值，且不想额外生成中间文件
- 关键限制：只能用 MySQL 内置函数，
REGEXP_REPLACE()必须是 8.0+；低版本只能组合SUBSTR()+CONCAT()拼接掩码，比如CONCAT('***', SUBSTR(@phone, 4, 4), '****') - 容易踩的坑：
SET phone = REGEXP_REPLACE(@phone, '^(\d{3})\d{4}(\d{4})$', '$1****$2')里，如果@phone是空或 NULL，结果会是 NULL——得加IFNULL或COALESCE包一层 - 示例语句：
LOAD DATA INFILE '/tmp/users.csv' INTO TABLE users FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (@name, @phone, @email) SET name = @name, phone = IF(@phone REGEXP '^[1-9]\d{10}$', CONCAT('***', SUBSTR(@phone, 4, 4), '****'), @phone), email = IF(@email REGEXP '.+@.+\..+', CONCAT(SUBSTR(@email, 1, 2), '**@**', SUBSTR(@email, -6)), @email);
为什么别在应用层做导入时脱敏
看起来最灵活的方式——用 Java/Python 读 SQL 文件、解析 AST、改值、再执行——实际掉坑最多。
- 常见错误现象：用
sqlparse解析后，遇到多行字符串、注释、转义单引号（'O''Reilly'）就错乱，脱敏位置偏移 - 兼容性问题：不同数据库的 SQL 方言差异大（如 MySQL 允许反引号，PostgreSQL 用双引号），同一套解析逻辑很难通用
- 真正麻烦的点不在正则本身，而在 SQL 的语法边界识别——比如一个字段值里恰好包含
VALUES (，会被误判成新 INSERT 开始 - 除非你明确控制 SQL 格式（比如全是单行 INSERT、无注释、无特殊字符），否则优先走文件预处理或
LOAD DATA的 SET 机制
真正卡住人的，往往不是正则怎么写，而是没想清楚「脱敏动作该在哪一层发生」：数据库函数受限于版本，应用层解析又太重，最省心的其实是把 SQL 当纯文本，在导入管道最上游切一刀。
