如何避免SQL触发器对系统性能产生连锁影响

触发器里为什么不能查大表或调用存储过程？因为这会同步阻塞主事务——每行变更都得等结果返回，锁住源表，拖慢QPS，放大锁等待。所以，必须遵守规则：只允许索引单行查询，禁用含SQL的函数和存储过程，聚合逻辑全部移到异步队列。

触发器里为什么不能查大表或调用存储过程

具体原因如下：MySQL在AFTER INSERT里执行SELECT * FROM users WHERE id = NEW.user_id，表面上看没什么问题，但如果users表在id字段上没有索引，就会触发全表扫描——1000次插入意味着扫1000遍，性能直接崩掉。

存储过程的问题更隐蔽：CALL update_inventory()内部如果包含UPDATE stock SET qty = qty - 1 WHERE sku = ?，每次调用都会触发权限校验、上下文切换、执行计划重编译，开销远超直接写两行SQL。

• 只允许执行索引单行查询，比如SELECT status FROM config WHERE key = 'order_default'这种轻量操作。
• 禁用所有含SELECT或PERFORM的自定义函数（PostgreSQL）或存储过程（MySQL），这是底线。
• 如果必须复用逻辑，确认函数声明为DETERMINISTIC且不含SQL；否则宁可把DATE_FORMAT(NOW(), '%Y-%m-%d')这种代码直接展开，别图省事。

AFTER触发器更新同表为何容易死锁

原因在于它仍在原事务内，持有新行X锁的同时再去UPDATE其他行，极易和外部事务形成循环等待。典型错误：在AFTER INSERT ON orders里写UPDATE order_summary SET total = total + NEW.amount——这时orders新行已加X锁，又试图对order_summary某行加锁；而另一处业务代码可能先锁order_summary再锁orders，死锁就注定发生了。

• AFTER触发器禁止任何UPDATE或INSERT操作到当前表或其强关联主表，这一点必须严格执行。
• 所有聚合类逻辑一律移出：用INSERT INTO trigger_queue (event_type, ref_id) VALUES ('order_created', NEW.id)中转，由后台JOB消费。
• 中转表trigger_queue必须用InnoDB引擎，无二级索引，字段精简到只有id、table_name、event_type。

如何让触发器只响应真正有意义的变更

另一个常见问题是避免无差别执行。比如UPDATE user_profiles SET updated_at = NOW()，即使name和email都没变，也会触发AFTER UPDATE。如果触发器里还跟着查日志表、发通知，浪费就累积了。

• 使用IF OLD.status != NEW.status THEN显式过滤字段级变更，别用OLD.* != NEW.*——某些数据库会序列化整行比对，JSON或TEXT字段直接卡住。
• 高频写入表（如埋点日志）原则上禁用触发器，改用应用层批量写入 + 定时ETL补偿。
• 上线前一定要压测：对比开启/关闭触发器时的Innodb_row_lock_waits和平均响应时间，波动超过15%就得重构。

触发器数量和元数据锁争用的关系

每个触发器都注册在information_schema.TRIGGERS里，MySQL要加MDL锁读取元数据。如果表上有20个触发器，SHOW PROCESSLIST里常看到Waiting for table metadata lock，尤其在DDL期间。

• 定期清理：用SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db'检查总数，超标就合并。
• 合并逻辑：多个触发器如果做相似的事（比如都更新updated_at），统一成一个BEFORE UPDATE，用IF分支区分。
• 灰度开关：通过会话变量控制是否执行，比如开头加IF @disable_triggers IS NOT NULL THEN LEA VE proc_label; END IF;，方便线上应急。

真实瓶颈往往不在触发器本身，而在它隐式拉起的锁、查询和事务延长——这些影响很难被慢日志直接捕获。需要靠EXPLAIN FORMAT=TREE看执行计划里有没有子节点调用，以及SHOW ENGINE INNODB STATUS里锁等待的具体行，才能定位问题。