怎样利用MySQL中的触发器实现数据的审计日志追踪？

触发器中 INSERT INTO audit_log 未生效的主因是未指定触发时机（如 AFTER INSERT）或未用 DELIMITER 切换语句结束符；audit_log 表应采用最小可用结构，含 id、table_name、operation、record_id、old_data、new_data、user、created_at 字段，优先使用 JSON 类型而非 TEXT，并避免在 DELETE 触发器中做逻辑删除。

触发器里写 INSERT INTO audit_log 为什么没生效？

常见原因是触发器定义时没加 AFTER INSERT 或 BEFORE UPDATE 等明确时机，或者触发器体里漏了 DELIMITER 切换——MySQL 默认用分号结束语句，而触发器体内有多个语句时会提前终止定义。

实操建议：

• 必须用 DELIMITER $$ 开头，结尾用 $$，再恢复 DELIMITER ;
• 触发时机选 AFTER（确保主表操作已提交，避免事务回滚导致日志残留）
• 审计字段尽量用 VALUES(NEW.id)、OLD.updated_at 这类显式引用，别依赖 LAST_INSERT_ID() 或 NOW() 多次调用（可能因并发或延迟产生偏差）

audit_log 表结构怎么设计才不容易翻车？

字段太少存不下上下文，太多又拖慢主表 DML 性能。核心是平衡可追溯性与写入开销。

推荐最小可用结构：

• id BIGINT AUTO_INCREMENT（不用 UUID，避免索引碎片）
• table_name VARCHAR(64) NOT NULL（记录被操作的表名）
• operation ENUM('INSERT','UPDATE','DELETE') NOT NULL
• record_id BIGINT NULL（对应主表主键，UPDATE/DELETE 时必填，INSERT 可从 NEW.id 获取）
• old_data JSON NULL（仅 UPDATE/DELETE 时存 JSON_OBJECT('name', OLD.name, 'status', OLD.status)）
• new_data JSON NULL（仅 INSERT/UPDATE 时存 JSON_OBJECT('name', NEW.name, 'status', NEW.status)）
• user VARCHAR(128) DEFAULT CURRENT_USER（注意：触发器内 CURRENT_USER() 返回的是执行 SQL 的账号，不是应用层用户）
• created_at DATETIME(6) DEFAULT CURRENT_TIMESTAMP(6)

别把 old_data 和 new_data 设成 TEXT —— JSON 类型支持部分索引和校验，TEXT 容易存脏数据且无法约束格式。

UPDATE 触发器里如何安全获取变化字段？

不能只比对 OLD.col != NEW.col，因为 NULL 和空字符串比较会返回 NULL，导致条件失效。

正确写法用 IS NULL 显式判断：

IF (OLD.name IS NULL) != (NEW.name IS NULL) OR OLD.name != NEW.name THEN  SET @changes = JSON_SET(@changes, '$.name', JSON_OBJECT('old', OLD.name, 'new', NEW.name));END IF;

更稳妥的做法是为每个需审计的字段单独判断，而不是试图动态拼 JSON —— 触发器不支持循环或反射，硬编码字段虽冗余但稳定。

注意点：

• 字段类型为 TIMESTAMP 或带默认值的列，在 UPDATE 时若未显式赋值，OLD 和 NEW 值可能相同，需结合 SELECT ... FOR UPDATE 或应用层传参确认是否真变更
• 别在触发器里调用存储过程处理 JSON —— 嵌套太深易超栈空间，也难调试

为什么线上禁用 DELETE 触发器做逻辑删除？

因为 AFTER DELETE 触发器执行时，原记录已不可查，OLD 虽可用但无法关联外键或关联查询，且一旦触发器报错（比如 audit_log 表满、磁盘写满），整个 DELETE 会失败，业务直接卡住。

替代方案更可靠：

• 主表加 is_deleted TINYINT DEFAULT 0 字段，用 UPDATE ... SET is_deleted = 1 替代物理删除
• 审计日志统一走 AFTER UPDATE，通过判断 OLD.is_deleted = 0 AND NEW.is_deleted = 1 来捕获“删除”动作
• 真正需要物理删时，走独立运维脚本，绕过触发器，同时人工归档 audit_log 对应记录

触发器本质是隐式耦合，越关键的操作越要控制它的作用域——审计可以容忍少量丢失，但主业务不能因日志失败而中断。