UPDATE触发器必须用AFTER而非BEFORE，以确保OLD和NEW值真实稳定；SQLite不支持AFTER，需改用应用层拦截；禁止在触发器内修改原表；审计推荐JSON存整行快照并显式传操作人身份。
UPDATE触发器必须用AFTER而非BEFORE
BEFORE UPDATE里OLD和NEW值不稳定，尤其在涉及计算列、默认值或约束校验时，可能取到NULL或未生效值；AFTER UPDATE才能确保主表变更已落盘，OLD.*和NEW.*反映真实状态。MySQL、PostgreSQL、SQL Server都支持AFTER UPDATE，但SQLite不支持——若用SQLite，得改用应用层拦截或临时表缓存OLD行。
- 别在BEFORE里写INSERT INTO audit_log，否则日志可能记录错误的“旧值”
- 触发器内禁止再UPDATE或DELETE原表，MySQL会报ERROR 1442，PG会抛出“cannot update table in trigger”
- 如果业务允许延迟审计（比如容忍秒级偏差），可考虑用异步消息队列替代触发器，避开锁竞争
OLD和NEW字段引用要按场景严格区分
硬写OLD.id在INSERT触发器里会崩，同理，NEW.status在DELETE触发器里也不存在。UPDATE触发器是唯一能同时访问OLD.*和NEW.*的场景，但必须逐字段比对，否则无实质变更也记日志。
- 安全写法：
IF OLD.email != NEW.email OR OLD.phone != NEW.phone THEN ... - 避免
OLD.*投影到JSON时字段顺序错乱——MySQL用JSON_OBJECT('email', OLD.email, 'phone', OLD.phone)，别依赖JSON_OBJECT(*) - SQL Server中
DELETED/INSERTED是伪表，不能直接SELECT * FROM DELETED插入无结构目标表，必须显式列出列名
审计表字段设计别拆列，优先用JSON存快照
把old_status、new_status、old_amount、new_amount拆成独立字段，加个新字段就得改触发器+改表+改查询逻辑。用JSON一次性存整行，查的时候用JSON_EXTRACT(old_data, '$.status')或old_data->>'$.status'提取，扩展性好，也方便做全文检索（PG的jsonb_path_exists、MySQL的JSON_CONTAINS）。
- MySQL 5.7+：用
JSON类型，建表时设old_data JSON - PostgreSQL：用
jsonb，支持Gin索引，查得快 - SQL Server：用
NVARCHAR(MAX)+FOR JSON AUTO生成，别用XML——解析慢且难调试
操作人身份不能靠CURRENT_USER()硬取
连接池下CURRENT_USER()返回的是数据库账号（如app_user@%），不是真实操作者。真正可用的来源只有两个：应用层显式传参（如@operator_id），或从会话上下文提取（如SQL Server的ORIGINAL_LOGIN()、MySQL的USER()配合应用设置init_connect注入变量）。
- 触发器里别写
INSERT ... VALUES (... , CURRENT_USER(), ...) - SQL Server推荐
ORIGINAL_LOGIN()，它不受EXECUTE AS影响 - MySQL若无法改应用，可用
performance_schema.session_connect_attrs查program_name或os_user，但需提前开启相关instrumentation
触发器本身不解决高并发下的性能抖动，尤其当UPDATE语句本身已带WHERE条件扫描大量行时，触发器里再做JSON序列化+INSERT，容易成为瓶颈。真要压测，先关掉触发器跑基准，再开，对比TPS下降幅度——超过15%就得考虑异步落库或批量合并。
