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

触发器里不能查大表或调用存储过程，因会同步阻塞主事务、放大锁等待、拖慢QPS；必须仅用索引单行查询，禁用含SQL的函数和存储过程，聚合逻辑应移至异步队列。

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

因为这些操作会同步阻塞主事务，每行变更都得等结果返回，锁住源表、拖慢QPS、放大锁等待。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 LEAVE proc_label; END IF;

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