优化mysql触发器需精简逻辑、避免复杂操作和大表查询，合理使用索引，减少锁竞争，必要时用异步或应用层处理替代，确保高效稳定。
触发器不是不能用，而是不能“重用”——高并发写入场景下，90%的性能问题来自触发器里多做了不该做的事。
避免在触发器里执行耗时操作
触发器运行在主事务内，任何延迟都会直接拖慢 INSERT/UPDATE 响应。常见错误包括：调用外部 API、执行带子查询的 UPDATE、往无索引日志表写大量记录、用游标遍历 NEW 行集合。
- 订单插入后实时统计用户总消费 → 改为写入
order_summary_queue表，由后台任务聚合 - 在
BEFORE INSERT中对email字段做正则校验 + DNS 查询 → 移到应用层，触发器只做格式标准化（如TRIM、LOWER） - 日志表
audit_log缺少created_at和table_name复合索引 → 导致INSERT时二级索引维护变慢
用 AFTER OF 指定字段 + IF 过滤无意义变更
MySQL 不支持 AFTER UPDATE OF col 语法，但可用 IF NEW.status != OLD.status 手动过滤；PostgreSQL 则原生支持 WHEN (OLD.status IS DISTINCT FROM NEW.status)。不加过滤的触发器，哪怕字段没变也会执行一次函数调用。
- 用户表更新时，只有
email或phone变更才写入contact_history - 批量导入时临时禁用触发器：
ALTER TABLE users DISABLE TRIGGER tg_user_audit，导入完再启用 - 避免在触发器中修改被触发表本身（如
AFTER INSERT ON orders再UPDATE orders），极易引发死锁或递归
优先选语句级触发器（PostgreSQL）或异步解耦（MySQL）
PostgreSQL 的 FOR EACH STATEMENT 触发器配合 NEW TABLE 过渡表，能把一万行更新的触发器调用从 10000 次降到 1 次；MySQL 没有过渡表，就得靠解耦。
- PostgreSQL 示例：用
INSERT INTO summary_cache SELECT COUNT(*), status FROM NEW TABLE GROUP BY status替代逐行累加 - MySQL 替代方案：触发器只写轻量消息到
binlog，用 Canal/Kafka 消费后更新缓存或发通知 - 若必须同步返回（如
updated_at字段），仅在触发器中赋值：SET NEW.updated_at = NOW()，其余全推到异步链路
索引与存储引擎必须协同优化
触发器里查的表、写的表、JOIN 的表，只要出现在 WHERE / ON / ORDER BY 中，就必须有对应索引。InnoDB 行锁依赖索引，没索引就升级为表锁 —— 高并发下等于自建瓶颈。
-
AFTER UPDATE ON orders中要查inventory表校验库存 →inventory(sku_id)必须有索引 - 日志类表高频写入，但查询少 → 删除冗余二级索引，只保留
(created_at, table_name)聚合查询所需索引 - 确认使用 InnoDB（而非 MyISAM），并检查
innodb_lock_wait_timeout是否过低（建议设为 50，避免短时争用直接报Lock wait timeout exceeded）
最常被忽略的一点：触发器不是“自动化的银弹”，而是数据库里最隐蔽的临界资源。它不报错，但会悄悄吃掉吞吐量；它不显眼，但可能让 INSERT 延迟从 2ms 升到 200ms。优化不是删掉它，而是把它从“什么都干”变成“只干最轻的一件事”。
