触发器中 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 性能。核心是平衡可追溯性与写入开销。
推荐最小可用结构：
-
idBIGINT AUTO_INCREMENT（不用 UUID，避免索引碎片） -
table_nameVARCHAR(64) NOT NULL（记录被操作的表名） -
operationENUM('INSERT','UPDATE','DELETE') NOT NULL -
record_idBIGINT NULL（对应主表主键，UPDATE/DELETE 时必填，INSERT 可从 NEW.id 获取） -
old_dataJSON NULL（仅 UPDATE/DELETE 时存JSON_OBJECT('name', OLD.name, 'status', OLD.status)） -
new_dataJSON NULL（仅 INSERT/UPDATE 时存JSON_OBJECT('name', NEW.name, 'status', NEW.status)） -
userVARCHAR(128) DEFAULT CURRENT_USER（注意：触发器内CURRENT_USER()返回的是执行 SQL 的账号，不是应用层用户） -
created_atDATETIME(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 对应记录
触发器本质是隐式耦合，越关键的操作越要控制它的作用域——审计可以容忍少量丢失，但主业务不能因日志失败而中断。
