合理设计触发器可提升性能，需减少复杂逻辑、优先用语句级和AFTER触发器、选择高效函数语言，并控制数量与依赖，定期审查执行计划以持续优化。
PostgreSQL触发器在提升数据完整性和业务逻辑自动化方面非常有用，但如果设计不当，容易成为性能瓶颈。特别是在高频写入或复杂逻辑场景下，触发器可能显著拖慢INSERT、UPDATE、DELETE操作。要优化触发器性能，需从设计、实现和使用方式多方面入手。
减少触发器中的复杂逻辑
触发器函数中执行的代码应尽可能轻量。避免在触发器内进行大量计算、复杂查询或跨表JOIN操作。
- 将非关键逻辑移出触发器，改由应用层或定时任务处理
- 如必须查询其他表，确保相关字段有适当索引
- 避免在行级触发器中执行耗时函数，比如字符串解析、网络请求等
合理选择触发器级别和时机
PostgreSQL支持行级（FOR EACH ROW）和语句级（FOR EACH STATEMENT）触发器。行级触发器每行都会执行一次，高并发写入时开销大。
- 如果逻辑只关心整体操作而非单行变化，优先使用语句级触发器
- 尽量使用 AFTER 触发器而非 BEFORE，除非需要修改 NEW 行数据。BEFORE 触发器会阻塞写入流程
- 仅在必要时启用触发器，可通过条件判断减少执行次数，例如：WHEN (OLD.status IS DISTINCT FROM NEW.status)
优化触发器函数语言选择
触发器函数可用 PL/pgSQL、PL/Python、SQL 等语言编写。不同语言性能差异明显。
- 优先使用 SQL 或 PL/pgSQL，原生支持更好，执行效率高
- 避免使用解释型语言（如 PL/Python）处理高频调用逻辑
- 若函数被频繁调用，标记为 IMMUTABLE 或 STRICT 可帮助优化器做判断
控制触发器数量与依赖关系
多个触发器按名称排序依次执行，过多或存在循环依赖会增加延迟。
- 合并功能相近的触发器，减少调用次数
- 避免触发器链式调用导致的“雪崩效应”
- 使用 pg_trigger 系统表监控触发器状态，及时清理无用触发器
基本上就这些。触发器不是越少越好，而是要在保证业务正确的前提下，做到最小化影响。定期审查触发器执行计划和运行日志，结合 EXPLAIN ANALYZE 分析其实际开销，才能持续优化性能。
