BEFORE触发器需显式赋值NEW字段以修改数据，AFTER触发器无法修改当前行但可执行日志等事后操作；MySQL与PostgreSQL在触发时机、递归限制及语法支持上差异显著。
BEFORE 触发器改写 INSERT/UPDATE 值时，新值必须显式赋值给 NEW
BEFORE 触发器的核心作用是“在语句真正执行前干预数据”，比如自动填充时间戳、标准化字段、校验逻辑。但它不会自动把修改反映到插入或更新的数据上——你得亲手把值塞进 NEW.column_name。
常见错误现象：INSERT INTO users (name) VALUES ('alice') 触发 BEFORE 触发器想补上 created_at，但没写 SET NEW.created_at = NOW()，结果该字段仍是 NULL 或默认值。
- 只读访问
OLD（UPDATE/DELETE 时可用），只写访问NEW（INSERT/UPDATE 时可用） -
NEW是一个可修改的行级上下文，不是变量，不能用:=或=直接赋整个结构体 - 对
NEW.id赋值后，若表主键是自增，MySQL 会忽略该值并仍走自增逻辑；PostgreSQL 则可能报错或覆盖，取决于定义 - 示例：
CREATE TRIGGER set_created_at BEFORE INSERT ON users FOR EACH ROW SET NEW.created_at = NOW();
AFTER 触发器无法修改当前语句涉及的行数据
AFTER 触发器只能“响应”已落地的操作，适合做日志记录、异步通知、关联表同步等事后动作。它读得到 OLD 和 NEW，但写它们无效——任何对 NEW.column 的赋值都不会影响刚插入/更新的那行。
使用场景：用户注册成功后，在 user_logs 表里记一笔；订单状态变更为 ‘shipped’ 后，调用 CALL notify_warehouse(...) 存储过程。
- 试图在 AFTER 中写
SET NEW.status = 'processed'完全无效果，也不报错 - 如果需要“联动更新其他表”，必须用
UPDATE other_table SET ... WHERE id = NEW.other_id这类显式语句 - 注意事务边界：AFTER 触发器和原语句在同一事务中，回滚会一并撤销
- 性能敏感操作（如发 HTTP 请求）千万别放这里，会拖慢主 DML 执行
MySQL 和 PostgreSQL 对触发器时机的支持差异
语法看着像，行为差得远。MySQL 只支持 BEFORE 和 AFTER，且每个事件最多一个触发器；PostgreSQL 支持更多时机（INSTEAD OF、FOR EACH STATEMENT / ROW），还能同一事件挂多个触发器并控制顺序。
容易踩的坑：
- MySQL 不允许在 BEFORE 触发器里对本表做 INSERT/UPDATE/DELETE（会报
Can't update table 'xxx' in stored function/trigger），PostgreSQL 允许但需小心递归 - PostgreSQL 的
INSTEAD OF触发器可用于视图，MySQL 没这功能 - MySQL 触发器不支持条件触发（如
WHEN (NEW.amount > 1000)），得靠IF块手动判断；PostgreSQL 支持WHEN子句过滤 - 参数差异：MySQL 用
NEW/OLD，PostgreSQL 用NEW/OLD但需在函数体里声明为RECORD类型
触发器里调用存储过程或外部服务的风险点
看似方便，实则埋雷。触发器生命周期短、上下文受限，不适合承担复杂逻辑。
典型问题：
- MySQL 存储过程中调用
SLEEP()或长耗时查询，会卡住整个事务，影响并发写入 - 试图在触发器里用
SELECT ... INTO OUTFILE或发起 HTTP 请求（哪怕通过 UDF），多数环境默认禁用或权限不足 - PostgreSQL 中触发器函数若抛出异常（
RAISE EXCEPTION），会直接导致原 DML 失败回滚，而你可能只想跳过某条日志记录 - 调试困难：触发器静默失败时，错误常被吞掉，日志也不一定输出，建议用
INSERT INTO debug_log ...替代打印
真正该用触发器的地方不多：字段自动填充、简单约束增强、审计字段维护。稍复杂一点的联动，优先考虑应用层处理或定时任务补漏。
