审计时查不到变更记录主因是误用INNER JOIN导致无日志的主表记录被过滤，应改用LEFT JOIN并配合WHERE log.id IS NULL识别未变更数据；需注意时区统一、索引优化及日志语义完整性。
JOIN审计时为什么查不到变更记录
常见现象是用INNER JOIN关联主表和日志表后，部分主记录“消失”了——比如用户表有100条，但JOIN日志表后只剩32条。这不是数据丢了，而是INNER JOIN只保留两边都匹配的行。审计场景下，你通常需要知道“哪些没被改过”，所以必须用LEFT JOIN，把主表全留下，日志字段为NULL就代表无变更。
- 别用
INNER JOIN做完整性审计，它天然过滤掉无日志的记录 -
LEFT JOIN后加WHERE log.id IS NULL能快速定位长期未变更的脏数据 - 注意日志表可能有多个版本记录，
ON main.id = log.main_id AND log.action = 'UPDATE'要写清条件，否则会重复膨胀结果
时间范围错位导致漏审或重审
审计常按“最近7天”筛选，但如果日志表的created_at是UTC时间，而主表用的是本地时区，直接WHERE log.created_at >= NOW() - INTERVAL 7 DAY就会漏掉跨时区的变更。更隐蔽的是：日志插入延迟（比如异步写入），某条记录实际发生在昨天，但日志落库在今天凌晨，会被当前查询忽略。
- 统一转换时区：
WHERE CONVERT_TZ(log.created_at, '+00:00', '+08:00') >= DATE_SUB(NOW(), INTERVAL 7 DAY) - 审计窗口建议多留缓冲：查“最近7天”就设成
INTERVAL 8 DAY，再用GROUP BY main.id去重 - 避免用
NOW()做基准，换成固定时间点（如'2024-05-20 00:00:00'）便于复现和比对
日志表缺少索引拖慢审计查询
一个没加索引的日志表，JOIN时执行计划显示type: ALL，10万行日志就能让查询从毫秒级涨到20秒以上。尤其当你要按main_id和action联合过滤时，单列索引效果有限。
- 至少建复合索引：
ALTER TABLE change_log ADD INDEX idx_main_action_time (main_id, action, created_at) - 如果审计只查
UPDATE，可加WHERE action = 'UPDATE'前缀索引提升效率 - 别依赖主键索引：日志表主键通常是自增
id，对main_idJOIN毫无帮助
变更字段值被覆盖导致比对失真
日志表如果只存old_value和new_value两个TEXT字段，遇到JSON或长文本变更，就无法精确判断是否真有变化——比如前后都是{"status":"active"}，但空格/换行不同，字符串比对会误报。更糟的是，有些系统日志只记变更后的快照，不存旧值，根本没法回溯差异。
- 优先用结构化字段：把
status、amount等拆成独立列，避免全量TEXT比对 - 加
md5(old_data) != md5(new_data)作为第一层快速过滤，再对命中的行做细粒度解析 - 警惕日志截断：MySQL的
TEXT默认只索引前1000字符，WHERE old_value = 'xxx'可能查不到被截断的记录
关联日志做审计，最难的不是写SQL，而是搞清日志怎么生成、什么时候写、字段是否可信。很多问题表面是JOIN写错了，其实是日志采集链路本身有盲区——比如软删除没记日志，或者批量更新只记了一条总日志。先确认日志表的语义完整性，再动JOIN。
