触发器update未生效的主因是执行路径被跳过、new/old误用、跨表更新缺失显式语句、异常被静默吞没或触发器未启用；需加日志验证调用、分路径测试、检查return与where条件、捕获异常并查启用状态。
触发器里写了UPDATE但没生效，先看是否跳过了执行路径
触发器代码看似完整，但IF条件不满足、WHEN子句为false、或提前RETURN都会让后续语句完全不运行。比如在PostgreSQL中写了一个BEFORE INSERT触发器，里面用IF NEW.status = 'draft' THEN ... END IF;，但实际插入的是'published'，整个块就静默跳过。
实操建议：
- 在触发器开头加日志（如
RAISE NOTICE 'trigger fired for %', NEW.id;），确认它真被调用了 - 把所有
IF/CASE分支展开测试：手动构造满足各分支条件的数据插入/更新一遍 - 检查是否有
RETURN NULL（尤其在BEFORE触发器中）——这会直接取消原操作，连INSERT都可能被拦住
NEW和OLD变量被误读或未赋值，导致UPDATE目标错乱
触发器中对NEW字段的修改只影响当前行的“即将写入值”，不会自动同步到其他表；如果想更新另一张表，必须显式写UPDATE other_table SET ... WHERE ...。常见错误是以为改了NEW.price就能让订单表价格联动变，其实只是改了本次插入的那行临时值。
实操建议：
- 区分场景：
BEFORE触发器可修改NEW来影响本行入库值；AFTER触发器不能改NEW，只能做副作用操作（如发通知、改其他表） - 涉及跨表更新时，务必检查
WHERE条件是否能精准定位目标行——比如用NEW.user_id去更新user_profile，但该ID在目标表里不存在，UPDATE返回0行影响却无报错 - MySQL中注意
NEW字段名大小写敏感（尤其开启lower_case_table_names=0时），NEW.User_ID和NEW.user_id可能不是同一个
触发器内部事务被隐式回滚，但外部看不到错误
触发器里执行的SQL一旦出错（如违反外键、唯一约束、类型转换失败），整个触发器+原DML操作会一起回滚。但很多客户端或ORM只显示“Query OK”，掩盖了内部失败。
实操建议：
- 在触发器中用
BEGIN ... EXCEPTION（PostgreSQL）或DECLARE EXIT HANDLER（MySQL）捕获异常，并RAISE或写日志，否则错误被吞掉 - 避免在触发器里调用不可靠的存储过程或外部函数——它们失败时未必抛出可捕获异常
- MySQL 8.0+中，若触发器内有
INSERT INTO t SELECT ...且目标表有ON DUPLICATE KEY UPDATE，部分情况下会静默跳过冲突行而不报错
触发器启用状态或作用对象被忽略
触发器创建成功不等于正在运行。PostgreSQL里可能被DISABLE TRIGGER禁用；MySQL中若表结构变更（如ALTER TABLE重命名字段），触发器可能失效但不报错；Oracle中触发器状态可能是DISABLED。
实操建议：
- 查状态：
SELECT tgname, tgenabled FROM pg_trigger WHERE tgname = 'your_trigger';（PostgreSQL）；SHOW TRIGGERS LIKE 'table_name';（MySQL） - 确认触发时机匹配：比如定义的是
BEFORE UPDATE，但你执行的是INSERT，自然不触发 - 注意触发器作用范围：有些数据库（如SQL Server）的DDL触发器默认只对当前数据库生效，跨库操作不会触发
RAISE输出，而不是依赖“执行成功”这个模糊反馈。
