触发器中禁止耗时操作，应仅保留必要校验，日志与通知等移至异步队列处理；慎用after insert和for each row，优先before insert赋值；批量导入宜禁用触发器；需通过性能监控定位真实瓶颈。

触发器里别做耗时操作，尤其是远程调用和复杂计算

SQL插入触发器一旦包含 INSERT INTO logs 以外的逻辑，比如调用 HTTP请求、解析JSON、查多张大表、写文件，就会把事务拖慢，阻塞主业务。MySQL/PostgreSQL 的行级锁会持续到触发器执行完，不是“插入完就释放”。

常见错误现象：INSERT 延迟从几毫秒飙升到几百毫秒，SHOW PROCESSLIST 看到大量 Updating 或 Waiting for table metadata lock。

• 只保留最必要的校验逻辑（如非空、格式检查），用 CHECK 约束或应用层前置更轻量
• 把日志记录、通知、统计汇总等搬出触发器，改用异步方式处理
• 避免在触发器里调用 SELECT ... FROM huge_table —— 即使加了索引，也可能触发全表扫描（尤其当WHERE条件含函数时）

用队列表 + 定时任务替代实时触发逻辑

把“必须做但不用马上做”的事，下沉到队列表，由后台任务消费。这是降低负载最直接有效的手段，且兼容所有主流数据库。

使用场景：用户注册后发欢迎邮件、订单插入后更新库存缓存、审计日志落ES。

• 建一张轻量队列表，字段至少包含 id、table_name、row_id、status、created_at
• 触发器里只做 INSERT INTO queue_table (table_name, row_id) VALUES ('orders', NEW.id) —— 这条语句基本无开销
• 用定时脚本（如Python + schedule）或消息队列消费者（如RabbitMQ监听DB变更）来批量处理 queue_table 中未完成的任务

注意：PostgreSQL 可用 pg_notify + LISTEN 实现近实时通知，MySQL 则建议用 binlog 解析（如 maxwell 或 canal），比轮询 queue_table 更高效。

触发器内慎用 AFTER INSERT 和 FOR EACH ROW

这两个关键词组合是性能杀手——每插一行就执行一次，批量插入（INSERT ... VALUES (...), (...), (...)）时会被放大N倍。

参数差异：MySQL 不支持 FOR EACH STATEMENT，只能逐行；PostgreSQL 支持，可用 WHEN (pg_trigger_depth() = 0) 控制只触发一次，但需手动判断上下文。

• 能用 BEFORE INSERT 就不用 AFTER —— 减少一次回表，也避免因触发器失败导致已插入数据回滚
• 如果只是想改新值（如生成UUID、补默认时间），用 BEFORE + 直接赋值 NEW.created_at := NOW()，比 AFTER 再 UPDATE 快得多
• 对批量导入场景，临时 DISABLE TRIGGER（PostgreSQL）或关掉 autocommit 并用应用层统一处理，比硬扛触发器更可控

监控和定位触发器真实开销不能只看慢查询日志

slow_query_log 或 pg_stat_statements 默认不单独统计触发器内部语句，容易误判“没慢SQL”，实际瓶颈就在触发器里。

性能影响：一个看似简单的 UPDATE counters SET total = total + 1 WHERE id = NEW.category_id，在高并发下可能成为热点行锁，引发大量 Lock wait timeout exceeded。

• MySQL：开启 performance_schema，查 events_statements_history_long 并过滤 TRIGGER 类型事件
• PostgreSQL：在触发器函数开头加 RAISE LOG 'trigger start %', clock_timestamp();，配合日志分析定位耗时点
• 压测时务必用真实数据量 + 并发数，不要只测单行插入 —— 触发器的扩展性缺陷往往在批量场景才暴露

最容易被忽略的是触发器嵌套：A触发B，B又触发C，层层叠加后事务时间翻倍，而日志里只显示最外层INSERT。上线前得人工捋清依赖链，能扁平化就别嵌套。