审计时查不到变更记录主因是误用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_id JOIN毫无帮助

变更字段值被覆盖导致比对失真

日志表如果只存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。