审计日志无法直接统计字段级变更次数，因原生日志仅记录完整SQL语句；需用正则提取SET后的字段名，MySQL需嵌套查询逐个提取，PostgreSQL可用regexp_matches+UNNEST获取全部字段，但均受限于性能、日志配置及ORM干扰。
审计日志里没有字段级变更记录，直接查 UPDATE 语句没用
多数数据库（如 MySQL、PostgreSQL）的原生审计日志（比如 MySQL 的 general_log 或 audit_log 插件）只记录完整 SQL 语句，不解析出具体被修改的字段。你看到的是 UPDATE users SET name = ?, email = ? WHERE id = ? 这种整行更新，无法直接统计“email 字段被改了多少次”。强行用 LIKE '%email = %' 模糊匹配会漏判（比如字段名出现在注释或字符串值中）、误判（比如 email_tmp 被当成 email），而且性能极差。
必须先提取字段名：用正则 + 嵌套查询拆解 SET 子句
以 MySQL 为例，假设审计日志存于表 audit_log，其中 sql_text 字段存原始语句。你需要分两步：先过滤出 UPDATE 语句，再从 SET 后面提取字段名。MySQL 8.0+ 支持 REGEXP_SUBSTR，但注意它一次只能取一个匹配，得配合 JSON_TABLE 或递归 CTE 才能拆多个字段——更稳妥的做法是用嵌套子查询配合字符串函数逐层剥离：
SELECT field_name, COUNT(*) AS update_count
FROM (
SELECT TRIM(REGEXP_SUBSTR(
SUBSTRING_INDEX(sql_text, 'SET', -1),
'[a-zA-Z_][a-zA-Z0-9_]*', 1
)) AS field_name
FROM audit_log
WHERE sql_text REGEXP '^UPDATE[[:space:]]+[a-zA-Z_][a-zA-Z0-9_]*[[:space:]]+SET'
) AS extracted
WHERE field_name != ''
GROUP BY field_name
ORDER BY update_count DESC
LIMIT 10;-
SUBSTRING_INDEX(..., 'SET', -1)取SET后全部内容，避免匹配到WHERE里的字段 -
REGEXP_SUBSTR(..., '[a-zA-Z_][a-zA-Z0-9_]*', 1)提取第一个合法标识符（即首字段），不处理多字段——这是关键妥协：单条语句含多个字段时，此写法只计第一个；真要全量统计，需用存储过程或导出后用 Python 处理 - 务必加
WHERE field_name != ''，否则空匹配会污染结果
PostgreSQL 怎么办：用 regexp_matches() 配合 UNNEST
PostgreSQL 更适合做字段级提取，因为 regexp_matches() 默认返回所有匹配项。假设日志表叫 pg_audit_log，字段为 statement：
SELECT field_name, COUNT(*) AS update_count
FROM (
SELECT (m)[1] AS field_name
FROM pg_audit_log,
UNNEST(regexp_matches(
SUBSTRING(statement FROM 'SET\s+([^\n;]+)'),
E'[a-zA-Z_][a-zA-Z0-9_]*',
'g'
)) AS m
WHERE statement ~* '^UPDATE'
) AS fields
GROUP BY field_name
ORDER BY update_count DESC;-
SUBSTRING(... FROM 'SET\s+([^\n;]+)')先截出SET后到换行或分号前的内容，比 MySQL 更精准 -
regexp_matches(..., 'g')的g标志确保返回所有字段名，UNNEST展开成行 - 注意 PostgreSQL 对大小写敏感，
~*是不区分大小写的正则匹配
别忘了权限和性能现实约束
这类分析本质是文本挖掘，不是标准 SQL 查询，实际落地时几个硬限制绕不开：
- 审计日志必须开启且保留足够久——MySQL 的
general_log默认关闭，开启后 I/O 压力明显；PG 的pg_audit插件需单独安装配置 - 正则表达式在大数据集上很慢，100 万条日志可能跑几分钟；建议先用
WHERE event_time > NOW() - INTERVAL 7 DAY限定时间范围 - 如果应用用 ORM（如 Hibernate、SQLAlchemy），生成的 SQL 常带参数占位符（
?或$1）或动态字段拼接，正则可能失效——这时得回溯到应用层日志或数据库触发器方案
真正想精确统计字段修改频次，靠日志正则只是临时手段；长期看，字段级变更审计需要数据库原生支持（如 Oracle 的 Fine-Grained Auditing）或在业务层埋点。
