触发器会拖慢 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。
