触发器里不能查大表或调用存储过程，因会同步阻塞主事务、放大锁等待、拖慢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里锁等待的具体行。
