MySQL触发器需用SELECT INTO查关联字段并赋值变量，加IF判断字段变更避免无效查询，检查ROW_COUNT()防NULL失败；历史表须用InnoDB、无外键、冗余存储、加change_type字段。
MySQL 触发器怎么写才能准确捕获 UPDATE 前后的关联字段？
关键不是“记录变更”，而是“知道哪条关联数据变了”。比如订单表 orders 更新时，要连带把对应客户姓名、商品名称这些来自 customers 和 products 表的字段也记进历史表——但触发器里不能直接 JOIN，OLD 和 NEW 只有当前行主键，其他字段得手动查。
实操建议：
- 在触发器里用
SELECT ... INTO从关联表查出需要的历史字段，赋值给局部变量，再插入历史表；不要试图在INSERT INTO history_table SELECT ... FROM orders JOIN customers ...这种写法——触发器上下文不支持多表查询目标 - 查关联数据前加
IF OLD.customer_id != NEW.customer_id OR OLD.product_id != NEW.product_id THEN判断，避免无意义查询（UPDATE 其他字段如备注时，客户/商品没变，就别去查了） - 务必在关联字段查询语句后检查
ROW_COUNT() = 0，防止外键失效或脏数据导致查不到，否则整个触发器会因未处理的 NULL 而静默失败
历史表结构设计不当会导致触发器报错 ERROR 1442
这个错误本质是 MySQL 禁止在触发器里修改“正在被操作的同一张表”，但很多人踩坑是因为：历史表用了和原表一样的引擎、或者加了触发器、或者定义了外键约束指向原表。
实操建议：
- 历史表必须用
ENGINE=InnoDB（别用 MyISAM），且 不能对原表设外键引用，否则 INSERT 历史行时会间接触发原表检查，触发 MySQL 的递归限制 - 历史表字段尽量冗余存储，比如存
customer_name VARCHAR(100)而不是customer_id BIGINT，省去后续反查，也规避关联表变动带来的历史失真 - 加一个
change_type ENUM('INSERT','UPDATE','DELETE')字段，配合触发器类型区分；别靠时间戳或主键顺序推断操作类型，不可靠
PostgreSQL 的 tg_op 和 OLD/NEW 在触发器函数里怎么安全取值？
PG 的触发器函数是独立的 PL/pgSQL 函数，OLD 和 NEW 是 RECORD 类型，直接点字段会报错“record type has no field”，必须先声明变量或用 ROW() 构造。
实操建议：
- 用
IF TG_OP = 'UPDATE' THEN明确分支，别依赖OLD IS DISTINCT FROM NEW判定——它对 NULL 不敏感，可能漏掉空值变更 - 取关联字段时，用
SELECT name INTO v_customer_name FROM customers WHERE id = NEW.customer_id;，且必须声明v_customer_name TEXT;，否则运行时报错 - INSERT 历史行前，用
IF v_customer_name IS NULL THEN v_customer_name := '[deleted]'; END IF;处理关联记录已被删的情况，避免历史表存 NULL 导致后续统计异常
触发器里调用函数或写复杂逻辑容易拖慢主业务
触发器是同步执行的，哪怕只多一次 SELECT 或字符串拼接，都会卡住原 SQL 的提交。线上订单更新慢，十次有八次是历史记录触发器干的。
实操建议：
- 禁止在触发器里调用自定义函数做耗时操作（比如 HTTP 请求、加密、大文本正则匹配）；所有计算逻辑压到应用层或异步任务里
- 历史表的
INSERT语句尽量精简：只插必要字段，禁用INSERT ... SELECT带子查询，改用 VALUES；索引只保留(table_name, record_id, created_at)这类高频查询组合 - 如果业务允许延迟，改用
INSERT DELAYED（MySQL）或监听pg_notify异步落库（PG），但得接受历史记录有秒级延迟
最麻烦的其实是跨库关联——触发器根本拿不到其他数据库里的客户信息，这时候要么放弃自动记录，要么把关联数据定期同步成本地快照表。没人提这事，但上线后第一个凌晨告警往往就是它。
