INSERT触发器应优先用BEFORE INSERT读取并修改NEW，显式指定审计表列名，通过应用透传操作人ID，禁用冗余索引，并注意REPLACE/ON DUPLICATE KEY UPDATE的触发盲区。
INSERT 触发器怎么写才能捕获完整变更数据
直接在 INSERT 触发器里读 NEW 就行，但很多人漏掉关键点：触发器执行时，主表插入尚未提交，NEW 是唯一可用的完整行数据源。别试图去查刚插进去的记录——可能还没落盘，也容易死锁。
-
BEFORE INSERT可修改NEW字段（比如自动补created_at），AFTER INSERT更适合只读审计，避免干扰原操作 - 如果审计表字段比原表多（比如加
op_type、op_time、op_user），必须显式列出插入列名，不能用INSERT INTO audit SELECT * - 注意字符集和排序规则一致性，否则
NEW.name插入到审计表时可能因 collation 冲突报错Illegal mix of collations
如何安全获取当前操作人（不是数据库用户）
数据库层面的 CURRENT_USER() 返回的是连接用户（比如 'app@10.0.1.%'），几乎没业务意义。真实操作人得靠应用层透传，常见做法是把用户 ID 塞进 session 变量或注释里。
- 应用端执行插入前先设变量：
SET @current_app_user = 12345;，触发器里用NEW.user_id := @current_app_user（BEFORE）或直接插入审计表：op_user = @current_app_user - 更稳的方式是在 SQL 注释里埋信息，比如
INSERT /* user_id=12345 */ INTO orders ...，但触发器无法解析注释，得靠代理层（如 ProxySQL）或应用日志兜底 - 千万别用
USER()或SYSTEM_USER()当操作人，它们反映的是连接身份，不是业务主体
审计表设计不当会拖慢主表写入
触发器是同步执行的，主表 INSERT 必须等审计写完才返回。一旦审计表没索引、没分区、或者跨库，延迟立刻暴露。
- 审计表务必禁用所有非必要索引，只保留按时间范围查询需要的复合索引，比如
(op_time, table_name, op_type) - 避免在触发器里做复杂计算或调用函数（如
UUID()、JSON_OBJECT()），MySQL 5.7 对 JSON 函数在触发器中支持有限，8.0 虽支持但性能损耗明显 - 如果审计量大（日均百万+），考虑把触发器逻辑换成应用层双写，或用 binlog 解析异步补全，别硬扛在事务里
INSERT 触发器无法覆盖 REPLACE 或 INSERT ... ON DUPLICATE KEY UPDATE 场景
REPLACE INTO 实际是 DELETE + INSERT，会触发 DELETE 和 INSERT 两个触发器；而 INSERT ... ON DUPLICATE KEY UPDATE 只触发 INSERT 触发器（即使走的是 update 分支），这是 MySQL 的行为盲区。
- 想审计
ON DUPLICATE KEY UPDATE的实际更新动作，只能改用BEFORE INSERT判断是否存在冲突键，再手动记录“拟更新”行为——但这已超出纯触发器能力 -
REPLACE触发的DELETE触发器拿不到原始插入值，因为OLD是删除前的行，但你通常想对比“删了什么”和“插了什么”，得靠审计表自己留历史快照 - 最稳妥的底线：只要业务用了
REPLACE或ON DUPLICATE KEY UPDATE，就别只信INSERT触发器，得结合 binlog 或应用层日志对账
真正难的不是写触发器，是厘清“谁在什么上下文里改了什么”——数据库看到的只是语句结果，不是业务意图。审计字段要不要存 JSON 全量快照，要不要关联事务 ID，这些决定往往在触发器之外就定死了。
