结论：MySQL触发器中调用COUNT()、SUM()等聚合函数是性能高危操作，应禁用而非优化；因其在行级同步事务中强制全表/索引扫描，引发锁表、慢查与事务堆积，且不支持GROUP BY和结果集赋值；推荐用冗余字段+应用层维护或异步标记+定时聚合替代。
直接说结论：在MySQL触发器里调用聚合函数（如COUNT()、SUM()、AVG()）是性能高危操作，绝大多数情况下应该禁用——不是“怎么优化”，而是“怎么绕开”。
为什么触发器里不能用聚合函数
触发器执行时处于主SQL事务中，且是行级同步执行。一旦你在BEFORE INSERT或AFTER UPDATE里写SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id，就等于每次插入/更新都强制触发一次全表扫描（或索引扫描），并发一上来立刻锁表、慢查询飙升、事务堆积。
- MySQL不支持在触发器中使用
GROUP BY或子查询结果集赋值给变量（会报ERROR 1415: Not allowed to return a result set from a function or trigger） - 即使加了索引，单次聚合仍需遍历匹配行；高频写入下，I/O和CPU开销呈线性甚至指数增长
- 无法利用查询缓存（触发器内查询默认不缓存）
替代方案：用冗余字段 + 应用层维护
把“需要聚合的结果”变成一个普通字段，由应用逻辑或定时任务维护，而非实时计算。这是最常用也最有效的解法。
- 在用户表加一个
order_count字段，每次创建订单后，应用层执行UPDATE users SET order_count = order_count + 1 WHERE id = ? - 避免在触发器里反查订单表；如果必须强一致性，可改用
INSERT ... ON DUPLICATE KEY UPDATE原子更新 - 对历史数据补全：用
UPDATE users u JOIN (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) o ON u.id = o.user_id SET u.order_count = o.c一次性初始化
真要保留触发器逻辑？那就只做标记，别做计算
如果业务强要求“变更即感知”，但又不能接受性能损失，唯一安全做法是：触发器只写轻量标记，把聚合留给异步处理。
- 建一张
pending_aggregations表，字段为table_name、record_id、agg_type（如'user_order_count'）、created_at - 触发器里只执行
INSERT INTO pending_aggregations VALUES ('orders', NEW.user_id, 'user_order_count', NOW()) - 后台用定时任务（如每分钟）批量读取并更新对应统计字段，完成后
DELETE标记行 - 注意加
WHERE created_at 防止重复处理
特别提醒：别碰自定义聚合函数 + 触发器组合
有人想用C写的自定义聚合函数（如CREATE AGGREGATE FUNCTION my_avg）来“加速”触发器里的计算——这反而更糟。因为：
- 自定义函数必须注册为
SONAME，加载依赖系统权限，生产环境部署复杂度陡增 - 它依然跑在触发器事务内，不会跳过锁、不会异步，只是把慢换成了另一种慢
-
xxx_add等回调函数若未做内存复用或状态缓存，可能比原生AVG()还慢
真正需要聚合分析的场景，应该用物化视图（MySQL 8.0+可用CREATE TABLE ... AS SELECT定期刷新）、汇总表或OLAP引擎（如ClickHouse），而不是塞进DML触发器里。
