触发器会拖慢INSERT/UPDATE性能，因其是同步阻塞操作；高频写入表禁用复杂触发器，仅在低频强一致性场景（如审计、冗余统计）谨慎使用，并优先考虑定时刷新等异步方案。
触发器会拖慢 INSERT/UPDATE 性能，别在高频写入表上加复杂逻辑
MySQL 触发器在 BEFORE 或 AFTER 事件中执行 SQL，本质是同步阻塞操作。一旦触发器里包含多表 JOIN、子查询、或调用 SELECT 查询（尤其没走索引），整个 DML 语句就会卡住等它跑完。
常见踩坑场景：
- 在订单表
orders的AFTER INSERT触发器里，查用户积分表并更新——每下一单就触发一次全表扫描 - 触发器内用
(SELECT COUNT(*) FROM ...)做校验，COUNT 没走索引且表数据量大 - 触发器调用自定义函数，而该函数内部又含查询，形成隐式嵌套
实操建议：
- 把触发器里的
SELECT拆出来，在应用层做预加载，用主键 ID 批量查一次搞定 - 必须查的字段，确保被查表有覆盖索引，例如
SELECT status, updated_at FROM logs WHERE order_id = ?要有(order_id, status, updated_at)复合索引 - 高频写入表（如日志、消息队列中间表）禁止加触发器；低频但强一致性要求的场景（如账户余额变更审计）才考虑
用触发器维护冗余统计字段，比实时 GROUP BY 查询快一个数量级
当业务频繁执行类似 SELECT category, COUNT(*) FROM products GROUP BY category，且 products 表超过 10 万行时，每次查都要全表扫描 + 文件排序。改用触发器维护一张 category_stats 表，查询直接走主键，毫秒级返回。
示例结构与触发逻辑：
CREATE TABLE category_stats ( category VARCHAR(50) PRIMARY KEY, product_count INT DEFAULT 0 ); <p>DELIMITER $$ CREATE TRIGGER tr_product_insert AFTER INSERT ON products FOR EACH ROW BEGIN INSERT INTO category_stats (category, product_count) VALUES (NEW.category, 1) ON DUPLICATE KEY UPDATE product_count = product_count + 1; END$$</p><p>CREATE TRIGGER tr_product_delete AFTER DELETE ON products FOR EACH ROW BEGIN UPDATE category_stats SET product_count = product_count - 1 WHERE category = OLD.category; END$$ DELIMITER ;
注意点：
-
ON DUPLICATE KEY UPDATE比先SELECT再INSERT/UPDATE更安全，避免并发冲突 - 删除触发器里不能用
DELETE FROM category_stats WHERE product_count = 0—— 触发器内删自己会导致死锁或不可预测行为 - 如果
category允许为NULL，需额外处理，因为PRIMARY KEY不接受NULL
触发器无法替代查询重写，EXPLAIN 看不出触发器开销
EXPLAIN 只分析你写的那条 SQL，不会展开触发器里的语句。你以为 INSERT INTO orders 很快，实际背后可能执行了 3 次 SELECT + 2 次 UPDATE，而这些完全不体现在 EXPLAIN 输出里。
定位真实耗时的方法：
- 开启
general_log或slow_query_log，看完整执行链路（注意日志体积爆炸风险） - 用
SHOW PROFILE FOR QUERY N查看某次查询各阶段耗时，其中trigger阶段会单独列出 - 对关键触发器加
SELECT BENCHMARK(1000000, 1)模拟 CPU 开销，快速验证是否成为瓶颈
更稳妥的做法：把触发器逻辑抽成存储过程，用 CALL update_stats('category', 'electronics') 显式调用，配合应用层控制执行时机和频率。
MySQL 8.0+ 的物化视图替代方案：用 CREATE REFERENCE + 定时刷新
严格来说 MySQL 没原生物化视图，但 8.0.23+ 支持 CREATE REFERENCE（实验性特性），配合事件调度器可模拟近实时汇总。相比触发器，它把计算从写路径卸载到后台线程，写入无感知。
简化实现思路：
- 建一张汇总表
daily_sales_summary，按天分区 - 用
CREATE EVENT每 5 分钟跑一次INSERT ... SELECT ... GROUP BY，只刷增量数据（基于created_at > last_run_time） - 应用查表时加
SQL_NO_CACHE提示，强制走磁盘最新数据（避免 Query Cache 误命中旧结果）
这种模式下，写入性能不受影响，查询延迟可控（最多 5 分钟），且所有逻辑暴露在 SQL 层，方便监控和调优。触发器适合强事务一致性场景；这种定时刷新更适合报表、BI、管理后台类查询。
真正难的是权衡：要不要为 0.1% 的一致性牺牲 30% 的写入吞吐？很多团队直到监控告警才发现触发器正在悄悄吃掉主库 CPU。
