MySQL触发器内无法开启独立事务，日志写入会随主事务回滚导致丢失；应使用独立日志表并接受不同步，避免NULL引用、关联查询及批量操作性能问题。
触发器里不能用事务控制日志表写入
MySQL 触发器运行在主语句的事务上下文中，INSERT/UPDATE/DELETE 失败时，触发器里的日志写入也会回滚——这会导致日志丢失。真实场景中你通常需要「操作失败也要留痕」，所以日志表必须用 ENGINE=BLACKHOLE 或更稳妥的方案：改用 INSERT ... SELECT + INSERT DELAYED（5.6+ 已废弃）或直接切到外部队列。但最简单有效的做法是：日志表用 InnoDB，并在触发器里显式开启独立事务——可惜 MySQL 不允许在触发器内执行 START TRANSACTION。因此实际能落地的方式只剩一个：把日志写入一张独立的、不参与业务事务的表，并接受它可能和主操作不同步。
触发器定义时要避开 NEW 和 OLD 的 NULL 引用
在 BEFORE INSERT 中，OLD 不存在；AFTER DELETE 中，NEW 不存在。直接引用会报错 ERROR 1363 (HY000): There is no OLD row in on INSERT。常见错误是写成 CONCAT(OLD.id, NEW.id) 这种无条件拼接。
-
BEFORE INSERT：只可用NEW，且注意字段是否允许为NULL，建议用IFNULL(NEW.field, '') -
BEFORE UPDATE：OLD和NEW都可用，但需判断值是否变化，避免冗余日志：IF OLD.status != NEW.status THEN ... END IF -
AFTER DELETE：只可用OLD，且别对OLD.created_at这类时间字段做函数运算（如DATE(OLD.created_at)），可能触发隐式类型转换导致索引失效
日志字段设计要兼容 DML 类型差异
同一张日志表要承载 INSERT、UPDATE、DELETE 三类操作，字段结构得灵活。硬塞所有业务字段进日志表既难维护又浪费空间。推荐方案是：日志表只存元信息 + 序列化变更内容。
- 必存字段：
table_name、operation（'INSERT'/'UPDATE'/'DELETE'）、row_id（主键值，OLD.id或NEW.id）、user（USER()）、created_at（NOW()） - 变更详情存为 JSON：
JSON_OBJECT('before', JSON_OBJECT('status', OLD.status), 'after', JSON_OBJECT('status', NEW.status))—— 注意 MySQL 5.7+ 才支持JSON_OBJECT，否则退化为CONCAT拼字符串 - 避免在触发器里查关联表（比如根据
NEW.user_id去users表查姓名），会拖慢主操作，且可能死锁
触发器性能隐患比想象中更早出现
单条 INSERT 触发一次日志写入看起来没问题，但批量导入（LOAD DATA INFILE 或 INSERT ... VALUES (...), (...), ...）会让触发器逐行执行，I/O 和 CPU 开销翻倍。线上曾有案例：10 万行插入因触发器日志写入耗时从 2s 涨到 47s。
- 测试阶段务必用真实数据量压测，不要只试单行
- 如果业务允许，把日志逻辑移到应用层（比如 ORM 的 save hook），由应用异步发 Kafka 或写本地文件再定时入库
- 实在要用触发器，至少给日志表加复合索引：
INDEX (table_name, created_at)，方便按表+时间范围归档
触发器不是银弹，它让日志「自动发生」，但也让问题更隐蔽——比如某次 UPDATE 看似成功，其实因触发器里字段长度超限被静默截断，日志也记错了。留痕的前提是先确保主逻辑稳定，否则日志只会帮你更快地发现哪一行崩了。
