触发器中UPDATE未生效的主因是外层事务回滚；MySQL禁止触发器修改同表数据会静默失败；PostgreSQL中AFTER触发器函数返回NULL将导致失效；需确认触发器已启用且无未捕获异常。
触发器里执行了UPDATE却没生效，先查是否被外层事务回滚
触发器本身不开启新事务，它完全依附于当前语句所在的事务上下文。如果触发器里的 UPDATE 看似执行了，但最终查不到变化，大概率是外层事务在触发器返回后发生了 ROLLBACK。
常见场景包括：
- 应用代码中用
try...catch捕获异常后未显式COMMIT，反而调用了ROLLBACK - 存储过程里触发器被调用，但该过程后续某步出错导致整事务回滚
- 使用 JDBC/ODBC 时设置了
autoCommit=false，但忘记commit()
验证方法：在触发器内加日志（如写入临时表或调用 RAISE NOTICE（PostgreSQL）/PRINT（SQL Server）），再检查事务最终是否提交——不要只看触发器有没有“跑过”。
MySQL中触发器不能修改同表数据，否则直接静默失败
MySQL 的 BEFORE 或 AFTER 触发器若尝试对触发它的同一张表执行 INSERT/UPDATE/DELETE，会报错 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，且整个语句会被终止，但部分客户端可能不显示该错误。
解决路径只有两条：
- 改用事件（
EVENT）或应用层异步处理，避开直接修改原表 - 把逻辑拆到外层语句中，比如原想在
AFTER INSERT里更新本表，改为在应用中INSERT后立刻UPDATE
注意：这个限制在 PostgreSQL、SQL Server 中不存在，但 MySQL 8.0 仍保持此行为。
触发器中调用存储过程，而过程里有未捕获的异常
触发器内调用的存储过程一旦抛出未处理的异常（比如除零、空值约束冲突、权限不足），会导致整个触发器中断，并使外层语句失败——即使你没看到明显报错，也可能因客户端忽略 warning 而误以为“执行成功”。
排查建议：
- 在触发器开头加
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION（MySQL）或BEGIN TRY...END TRY BEGIN CATCH...END CATCH（SQL Server）做兜底记录 - 检查被调用过程内部是否用了
SELECT返回结果集——某些驱动会把结果集当错误中断流程 - 确认过程里所有 DML 是否都明确指定了目标库和表名，避免因默认 schema 切换导致操作了错误表
PostgreSQL中触发器函数返回NULL导致AFTER触发器失效
在 PostgreSQL 中，AFTER 触发器函数必须返回 OLD 或 NEW（取决于触发时机），若返回 NULL，PostgreSQL 会跳过该触发器后续逻辑，且不报错。
典型错误写法：
CREATE OR REPLACE FUNCTION log_change() RETURNS TRIGGER AS $$ BEGIN INSERT INTO audit_log VALUES (NEW.id, NEW.name); RETURN; -- ← 这里隐式返回 NULL，AFTER 触发器就此结束 END; $$ LANGUAGE plpgsql;
正确写法是显式返回：
-
RETURN NEW;（对INSERT/UPDATE） -
RETURN OLD;（对DELETE）
这个点极难察觉，因为无任何提示，数据就是“莫名没变”——尤其当你复用了一个本为 BEFORE 写的函数时。
最常被忽略的是：触发器是否真的被触发了。别只盯着 SQL 逻辑，先用 SELECT pg_trigger.* FROM pg_trigger JOIN pg_class ON tgrelid = pg_class.oid WHERE relname = 'your_table'; 确认触发器存在且 tgenabled 是 O（enabled），而不是 D（disabled）或 R（replica）。
