Linux 上 Informix 触发器使用注意事项
一 命名与版本兼容
- 触发器名称在数据库中必须唯一，长度不超过18个字符，且以字母开头。创建时可指定 ENABLED（默认）或 DISABLED 状态以便平滑发布与回滚。触发事件支持 INSERT、UPDATE、DELETE；自 9.2x 起支持 SELECT 触发器，自 9.40 起支持 INSTEAD OF 触发器（用于不可更新视图）。在 BEFORE/AFTER 之后可使用 FOR EACH ROW 定义行级触发，并可在各阶段使用 WHEN(condition) 做条件过滤。
二 语义与限制
- 行级引用：INSERT 仅可引用 NEW；DELETE 仅可引用 OLD；UPDATE 可同时引用 OLD/NEW。在 BEFORE INSERT/UPDATE 中可对 NEW 的字段进行赋值；OLD 始终为只读。触发体中可执行 INSERT/UPDATE/DELETE 或 EXECUTE PROCEDURE/FUNCTION。
- 条件与粒度：WHEN 条件可放在 BEFORE/AFTER/FOR EACH ROW 阶段，便于实现如“仅当涨幅超过阈值才审计”的细粒度控制。
- 多触发器与列清单：同一表上，每个事件类型通常仅能定义一个触发器；但 UPDATE 可按列清单拆分多个触发器，且列清单需相互排斥（避免同一列被多个 UPDATE 触发器覆盖）。
- 语句级与行级：行级触发器使用 FOR EACH ROW；若未使用行级，则为语句级（对触发语句整体执行一次）。语句级 AFTER 触发器即使未命中行也会执行，行级则逐行执行。
- 常见误区：不能在触发器中直接对目标表做与触发事件相同的数据修改（例如 INSERT 触发器中再对同表 INSERT）以免产生递归或不可预期的结果；如需“替代操作”，应使用 INSTEAD OF 触发器或改为在应用/存储过程层控制。
三 性能与锁
- 触发器逻辑应尽量轻量（避免大事务、长循环、远程调用），只做必要的校验/审计/派生列计算，将复杂处理放到异步任务或批处理中。
- 行级触发器会随每行执行一次动作，易放大 I/O 与锁 争用；对高吞吐表应谨慎使用，必要时改为语句级或批量汇总写入。
- 关注触发动作对锁的影响（行锁/页锁/表锁）、事务时长与死锁风险；必要时通过拆分逻辑、减少触发体工作集、优化索引与执行计划来降低争用。
- 使用 SPL/UDR 时，注意触发器内调用的例程是否可缓存、是否产生额外解析与上下文切换；避免在触发器中执行高成本查询。
- 上线前评估对 CPU、内存、I/O 的影响，配合 onstat/onperf 等工具观察会话、锁与 I/O，必要时调整表/索引设计、分段与 PDQ 等参数。
四 可移植性与调试
- 不同版本对触发器的支持存在差异（如 SELECT/INSTEAD OF 的版本门槛），跨版本迁移时需核对语法与功能点；命名规则、保留字与大小写敏感性也需保持一致。
- 触发器内调用 UDF/存储过程 时，若需传递行值，可通过 ROW 类型构造与类型转换（例如
ROW(col1,col2)::ROW(col1 INT, col2 VARCHAR(30))）将行作为整体参数传递，避免逐列列举。
- 调试建议：先在测试库验证触发顺序、条件命中与性能；使用 RAISE EXCEPTION 抛出明确错误；必要时以 DISABLED 快速隔离问题，再逐步启用；保留触发器的 创建脚本与回滚脚本，并记录影响范围与依赖对象。
五 运维与变更管理
- 变更流程：任何 DDL（含触发器）应在维护窗口执行，先 DISABLE 相关触发器，完成数据与应用切换后再 ENABLE；全程配合备份与回滚预案。
- 依赖管理：触发器可能依赖表结构、索引、权限与 UDF；变更表结构（列增删改、类型变更）需同步评估触发器与 UDF 的兼容性。
- 审计与合规：将触发器用于审计时，控制写入频率与保留周期，避免审计表膨胀；必要时分区或定期归档。
- 监控与告警：对触发器的错误与性能建立监控（失败次数、执行时长、锁等待），并与应用告警联动，及时发现异常。
