禁用触发器比优化更直接，因for each row触发器在批量导入时按行调用，10万行即执行10万次，瓶颈在调用频次而非单次耗时，优化函数内部收效甚微。
禁用触发器比优化它更有效，但必须满足三个前提：业务不依赖其副作用、不在事务内操作、异常后能手动恢复启用。
为什么禁用比优化更直接
PostgreSQL 的 FOR EACH ROW 触发器在批量导入时会按行调用——10 万行数据就执行 10 万次函数。哪怕单次逻辑只做一次 INSERT INTO log_table 或调用 pg_notify，总延迟也会指数级上升。此时优化函数内部（比如加索引、改查询）收效甚微，因为瓶颈是调用频次，不是单次耗时。
常见错误现象包括：
- 导入脚本卡在
COPY后长时间无响应，pg_stat_activity显示状态为active且wait_event是ClientRead或Lock - 日志表写入量远超预期，但业务侧并未主动触发变更
- 同一张表的并发导入失败，报错
ERROR: cannot ALTER TABLE because it is being used by active queries
禁用与启用的正确姿势
必须在事务外执行 ALTER TABLE ... DISABLE TRIGGER，否则会触发错误：The context in which the current operation is executing does not allow for transaction control。
推荐操作顺序：
- 先确认当前触发器状态：
SELECT tgname, tgenabled FROM pg_trigger WHERE tgrelid = 'your_table'::regclass; - 禁用全部触发器：
ALTER TABLE your_table DISABLE TRIGGER ALL; - 执行
COPY或批量INSERT（建议包裹在BEGIN; ... COMMIT;中） - 启用触发器：
ALTER TABLE your_table ENABLE TRIGGER ALL; - 若需验证是否恢复，再查一遍
tgenabled字段，值应为O（originally enabled）或A（always enabled）
注意：DISABLE TRIGGER ALL 不影响约束触发器（如外键、唯一检查），那些由系统隐式管理，禁用需单独处理 NOT VALID 或 SET CONSTRAINTS。
哪些场景不能随便禁用
禁用不是银弹，以下情况需格外谨慎：
- 触发器承担关键业务逻辑，比如自动填充
created_at、校验字段组合唯一性、或更新关联统计表——禁用后数据可能不一致且无法自动修复 - 有 CDC 工具（如 Debezium）、逻辑复制或应用层监听
pg_notify依赖该触发器产生的事件 - 表被其他长期运行的服务轮询（例如定时任务查某标志位），而该标志位由触发器维护
- 导入脚本本身已嵌套在大事务中，又试图在其中执行
ALTER TABLE——会直接报错，必须拆出来
最容易被忽略的一点是：禁用期间发生的任何数据变更，都不会触发逻辑。如果导入中途失败，后续重试前必须手动检查并补全缺失的副作用（比如漏写的审计日志），否则监控或对账会出问题。
