MySQL中修改NEW字段值仅在BEFORE触发器中生效，AFTER中无效；PG需显式RETURN NEW/OLD，否则操作被跳过；触发器不可替代应用层校验，复杂逻辑应由应用处理。
触发器里改 NEW 字段值不生效？
MySQL 触发器中对 NEW.column_name 赋值，只在 BEFORE INSERT 或 BEFORE UPDATE 中有效；AFTER 触发器里改 NEW 完全被忽略，也不会报错。
- 必须用
BEFORE类型才能干预插入/更新前的数据状态 -
INSERT场景下，NEW是待插入行，可补默认值、修正格式（比如把空字符串转为NULL） -
UPDATE场景下，常用于拦截非法变更：若OLD.status = 'paid'但NEW.amount != OLD.amount，直接SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '已支付订单金额不可修改' - 注意：MySQL 8.0+ 支持
SIGNAL，低版本得靠写不存在的表来抛错（如INSERT INTO nonexistent_table VALUES()）
触发器校验 vs 应用层校验，哪个先崩？
触发器校验是数据库最后一道防线，但它不能替代应用层逻辑——一旦业务规则变复杂（比如要查另一张表、调外部 API），硬塞进触发器会导致锁表时间长、主从延迟飙升、调试困难。
- 简单一致性（如“价格不能为负”“邮箱格式需含@”）适合放触发器，稳定且绕不开
- 涉及多表 JOIN 判断、状态机流转、幂等性检查等，应该由应用控制，触发器只做原子性兜底（例如防止并发重复扣款时，用
SELECT ... FOR UPDATE+ 触发器双重保险） - 触发器里执行
SELECT查其他表，在高并发下极易成为性能瓶颈，尤其是没走索引或查大表时
PostgreSQL 的 BEFORE ROW 触发器怎么写才不踩坑？
PG 触发器函数返回值决定是否继续执行：返回 NULL 会跳过当前行操作，返回 NEW（修改后）或 OLD（原样）才继续。这点和 MySQL 不同，容易漏写 RETURN NEW 导致整条 INSERT 没反应。
- 函数体末尾必须有
RETURN NEW（BEFORE INSERT/UPDATE）或RETURN OLD（BEFORE DELETE） - 不要在触发器里做事务控制（
BEGIN/COMMIT），它天然运行在父事务中 - 如果校验失败，用
RAISE EXCEPTION 'xxx'，别用RETURN NULL模拟拒绝——后者不报错，应用层以为成功了 - 示例片段：
CREATE OR REPLACE FUNCTION check_stock() RETURNS TRIGGER AS $$ BEGIN IF NEW.quantity > (SELECT stock FROM products WHERE id = NEW.product_id) THEN RAISE EXCEPTION '库存不足'; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql;
触发器被禁用或失效的隐蔽原因
线上突然发现约束没起作用，大概率不是逻辑写错了，而是触发器本身没启用或被绕过了。
- MySQL 5.7+ 默认开启触发器，但若用
mysqldump --skip-triggers还原库，触发器不会重建 - 使用
LOAD DATA INFILE或mysqlimport时，即使有触发器，默认也不触发（需显式加SET SQL_LOG_BIN = 1并确认 binlog 格式） - PG 中若函数定义用了
VOLATILE且内部调了随机函数，可能被查询优化器提前剪枝，导致触发器不执行 - 最常被忽略的一点：ALTER TABLE … DISABLE TRIGGER ALL 之后忘了启用，尤其在批量数据迁移后
触发器不是魔法，它只是把校验逻辑从应用挪到了数据库进程里；一旦涉及跨事务、跨库、异步状态，它就无能为力。真正难的从来不是“怎么写”，而是“该不该写”。
