答案：优化触发器需拆分职责、移出耗时操作、避免重复查询、添加熔断与日志监控。应将多职责触发器拆为单一职责小触发器，用事件表替代外部调用，确保关联查询有索引，并通过配置开关和日志表实现可控可溯。
拆分逻辑：把“一个触发器干五件事”改成“五个小触发器各管一摊”
触发器变难维护，90%是因为它被塞进了太多职责：校验、日志、同步、计算、通知全挤在一个 CREATE TRIGGER 里。这不是代码复用，是逻辑耦合。数据库不支持“模块化导入”，但你可以用命名+职责分离来模拟——比如 trg_orders_before_insert_validate、trg_orders_after_insert_audit、trg_orders_after_insert_sync。每个只做一件事，失败时能快速定位到具体环节，而不是在一堆 IF 嵌套里翻三页找哪一行改了 NEW.status。
注意：BEFORE 和 AFTER 触发器不能同名，但可以共存于同一张表；MySQL 不允许同类型（如两个 AFTER INSERT）触发器作用于同一表，PostgreSQL 和 Oracle 支持按顺序执行，SQL Server 也支持多触发器，但需注意执行顺序不可控风险。
替换复杂业务逻辑：把积分计算、发邮件、调外部API这些搬出触发器
触发器里调 CALL send_email_proc() 或 INSERT INTO external_queue 看似省事，实则埋雷：一旦邮件服务超时，整个事务回滚；一旦队列表写失败，主表插入也被拖垮。真正的解法是只写入本地事件表，例如 event_queue，字段含 event_type、payload、status。再由独立的轮询服务或 CDC 工具消费该表。
- ✅ 正确做法：
INSERT INTO event_queue (event_type, payload) VALUES ('order_created', JSON_OBJECT('order_id', NEW.id)); - ❌ 高危操作：
CALL http_post('https://notify.example.com/', NEW.id);（多数数据库不原生支持，强行集成会破坏事务一致性） - ⚠️ 特别注意：Oracle 的
UTL_HTTP、SQL Server 的sp_OACreate虽然能发请求，但它们不在事务保护范围内，失败不会回滚主操作，极易造成状态不一致。
用虚拟表替代重复查询：别在触发器里反复 SELECT ... FROM orders WHERE id = NEW.order_id
行级触发器中，NEW 和 OLD 就是当前行的快照，所有字段值已就绪。如果触发器逻辑需要关联其他表（比如查用户等级），应优先考虑用 JOIN 或子查询一次性带出必要字段，而不是在循环里反复查。更关键的是：避免在 FOR EACH ROW 触发器中执行未加索引的 SELECT——批量插入 1 万行，就会执行 1 万次全表扫描。
举例：要根据 NEW.user_id 查用户风控等级，不要写：
SELECT risk_level INTO v_risk FROM users WHERE id = NEW.user_id;
而应提前确保 users(id) 有主键或唯一索引，并在触发器外建好物化视图或缓存表（如 user_risk_cache），或直接在主 SQL 中 JOIN 后传入——触发器本身不该承担数据聚合责任。
加熔断和日志开关：没监控的触发器就像没刹车的车
生产环境里，没人能保证触发器永远不出错。必须让它具备“自知之明”：记录每次执行耗时、影响行数、是否跳过（比如开关关闭）、错误堆栈。最简方式是在触发器开头加判断：
IF NOT EXISTS (SELECT 1 FROM config_flags WHERE key = 'trg_orders_enabled' AND value = 'true') THEN LEAVE proc_label; END IF;
再配合定期清理的 trigger_log 表，字段至少含 trigger_name、exec_time、affected_rows、error_message。别依赖 SHOW TRIGGERS 或日志文件——它们不记录执行结果。
真正容易被忽略的点是：触发器内无法直接获取当前事务 ID 或客户端 IP，MySQL 8.0+ 可用 CONNECTION_ID() 关联 slow log，PostgreSQL 可用 pg_backend_pid() + pg_stat_activity 关联，但这些都需要额外设计追踪链路。没有上下文标识的日志，等于没日志。
