SQL日志不脱敏等于裸奔，因其常记录明文密码、手机号、身份证号等敏感信息，一旦日志泄露即直接暴露凭证；最稳妥做法是仅对VALUES括号内各值和SET等号右侧赋值表达式进行正则脱敏，避免误伤字段名或函数。
日志里直接打印原始 INSERT、UPDATE 或带参数的 SELECT 语句，等于把数据库凭证、用户手机号、身份证号、银行卡号甚至明文密码全记在磁盘上——只要日志文件被拖走或误配权限，就等于送钥匙上门。
为什么 SQL 日志不脱敏就是裸奔
SQL 日志不是“执行记录”那么简单。它常包含：VALUES ('张三', '138****5678', 'pwd123!') 这类完整参数；错误堆栈里可能带 WHERE id = 'admin' AND password = '123456'；调试模式下还可能输出 SET @sql = CONCAT('UPDATE user SET token = ''', token_val, ''' WHERE id = ', uid) ——所有这些，一旦落到攻击者手里，都不需要爆破，直接复用。
更隐蔽的风险是：日志轮转后旧文件未加密归档、运维人员用 grep 查问题时顺手 cat 出整段日志发到协作群、CI/CD 流水线把日志上传到共享存储——这些操作本身合法，但前提是日志内容已脱敏。
只对 VALUES 和 SET 子句做正则替换最稳妥
全量替换 SQL 字符串容易误伤（比如把字段名 user_name 里的 name 当成敏感词干掉），也难覆盖嵌套结构。实际只需聚焦两个位置：
-
VALUES后括号内逗号分隔的每个值（含字符串、数字、NULL） -
SET后等号右侧的赋值表达式（排除函数调用如NOW()、UUID()）
示例正则（Python）：
import re
def desensitize_sql(sql):
# 脱敏 VALUES 中的字符串和数字（保留 NULL、true/false、函数）
sql = re.sub(r"VALUES\s*\(\s*([^)]*?)(?<!\b(NOW|UUID|CURRENT_TIMESTAMP|SYSDATE)\s*\(\s*\))\s*\)",
lambda m: "VALUES (" + re.sub(r"'[^']*'|\"[^\"]*\"|\b\d+\b", "'***'", m.group(1)) + ")",
sql, flags=re.IGNORECASE)
# 脱敏 SET 后等号右侧（跳过函数和 NULL）
sql = re.sub(r"SET\s+([^=]+)=\s*([^,;]+)(?=[,;]|$)",
lambda m: f"SET {m.group(1)} = ***",
sql, flags=re.IGNORECASE)
return sql注意：该逻辑不处理子查询、预编译占位符（如 ? 或 :id），也不碰 SELECT 的 WHERE 条件——除非你明确知道该条件含敏感字段（如 WHERE phone = ?），否则留白更安全。
别在生产环境无差别脱敏所有 SQL
过度脱敏会让日志失去诊断价值。比如把 UPDATE order SET status = 'paid' WHERE id = 12345 变成 UPDATE order SET status = *** WHERE id = ***，你就无法判断是单条更新失败，还是批量更新卡住。
推荐策略：
- 仅对
INSERT、UPDATE、DELETE语句启用脱敏 -
SELECT仅当语句中显式出现敏感字段名（如id_card、bank_no）时才触发脱敏 - 用日志级别控制：只在
DEBUG或TRACE级别记录完整 SQL，INFO级别强制脱敏
SQLAlchemy 用户可直接 hook engine.connect().execute() 前的事件，用 before_cursor_execute 拦截并脱敏；PHP PDO 则建议封装 exec() 和 prepare() 方法，在 bind 参数前统一清洗。
正则脱敏的边界很窄，别指望它解决所有问题
正则能对付简单字符串和数字，但对以下情况完全失效：
- JSON 字段里嵌套的手机号：
UPDATE user SET profile = '{"phone":"13812345678"}' WHERE id=1 - 拼接 SQL：
"UPDATE user SET token = '" + genToken() + "' WHERE id = " + uid - Base64 或十六进制编码的敏感值
这类必须回归应用层结构化处理：在 ORM 实体序列化前过滤字段，或在日志框架的 LogRecord 处理阶段做字段级脱敏。正则只是兜底手段，不是银弹。
