必须拒绝动态sql拼接@filter_sql，应改用预设参数开关（如@trim_fields、@case_mode）和内置函数批量清洗，禁用游标，触发器仅做轻量整形，批量操作须分批加事务并校验清洗效果。
通用清洗逻辑必须拒绝动态SQL拼接
硬塞 @filter_sql 这类字符串参数进存储过程，等于主动放弃参数化保护和执行计划缓存。一旦调用方传入恶意内容，EXEC(@filter_sql) 就会直接触发 SQL 注入；更糟的是，每次不同字符串都会生成新执行计划，缓存碎片严重。
真正可复用的做法是把清洗动作拆成明确、有限的控制开关：
-
@trim_fields VARCHAR(100) = 'name,email,phone'—— 仅接受预设字段名列表，内部用STRING_SPLIT()（SQL Server）或JSON_TABLE()（MySQL 8.0+）解析后逐字段处理 -
@case_mode TINYINT = 1—— 1=UPPER, 2=LOWER, 3=INITCAP，避免写IF @mode = 'upper' SET @sql = 'UPPER(...)' -
@date_format_style VARCHAR(10) = 'ymd'—— 限定为 'ymd' / 'mdy' / 'iso'，不支持自由格式字符串
字段级清洗优先用内置函数，别碰游标
在 SQL Server 中用 CURSOR 对 5 万行电话字段逐行 REPLACE(REPLACE(...))，执行时间可能比等价的集合语句慢 15 倍以上。MySQL 8.0 的 REGEXP_REPLACE() 和 SQL Server 的 TRANSLATE() 都是为这类场景设计的。
典型安全写法：
UPDATE target_table SET email = LOWER(TRIM(email)), phone = REGEXP_REPLACE(phone, '[^0-9]', '') -- MySQL 8.0+ WHERE status = 'raw' AND (email IS NULL OR phone REGEXP '[^0-9]');
注意点：
- 必须加
WHERE条件限制范围，否则全表锁死 - MySQL 中
REGEXP_REPLACE()不支持捕获组（如$1），只能做固定模式替换 - SQL Server 2016+ 推荐用
STRING_SPLIT()+FOR XML替代游标拆分逗号字符串
触发器里只做 BEFORE INSERT/UPDATE 的字段整形
触发器不是数据清洗平台，它只是“入库前最后一道轻量过滤”。适合做的事只有三类：去空格、转大小写、补默认值。任何跨表查、正则提取、JSON 解析都该立刻移出触发器。
PostgreSQL 示例（BEFORE INSERT）：
NEW.email := LOWER(TRIM(NEW.email));
NEW.phone := REGEXP_REPLACE(NEW.phone, '[^0-9]', '', 'g');
IF NEW.email !~ '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$' THEN
RAISE EXCEPTION 'invalid email format';
END IF;
MySQL 注意：:= 不合法，必须写成 SET NEW.email = LOWER(TRIM(NEW.email));；且不能在触发器里调用自定义函数（除非明确标记 READS SQL DATA）。
批量清洗必须分批 + 显式事务边界
单次 UPDATE 处理超 5 万行，在多数生产库上会触发锁升级、日志暴涨甚至超时中断。不要指望 “一次跑完”，要接受“分片提交”才是常态。
SQL Server 分批模板：
DECLARE @batch_size INT = 10000;
WHILE @@ROWCOUNT > 0
BEGIN
UPDATE TOP (@batch_size) t
SET phone = REPLACE(REPLACE(phone, '-', ''), ' ', '')
FROM raw_data t
WHERE status = 'pending'
AND phone LIKE '%[- ]%';
END
关键约束：
- 每次只改
TOP (@batch_size)行，避免长事务 - WHERE 条件必须能走索引（例如
status = 'pending'上建索引） - 别在过程中写
COMMIT或SAVE TRANSACTION—— 调用方应控制事务生命周期
最易被忽略的一点：清洗前后必须校验脏数据比例。比如执行完电话清洗，立刻查 SELECT COUNT(*) FROM raw_data WHERE phone REGEXP '[^0-9]'，结果非零就得告警，而不是默认“大概清完了”。
