触发器中不能用select...into给用户变量赋值，且禁止查询本表；应声明局部变量并用子查询或异步方式统计，避免全表count(*)导致性能骤降。
触发器里不能用 SELECT ... INTO 给变量赋值？
MySQL 8.0+ 的 BEFORE INSERT 或 BEFORE UPDATE 触发器中，想把某张表的聚合结果（比如当前用户订单总数）算出来塞进新行字段，直接写 SELECT COUNT(*) INTO @cnt FROM orders WHERE user_id = NEW.user_id 是错的——INTO 在触发器里只支持写入**局部变量**（用 DECLARE 声明的），不支持用户变量（@cnt）。更关键的是，**触发器内禁止对本表做 DML 查询**（如 SELECT 当前表数据），否则会报错 Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
实操建议：
- 改用
DECLARE cnt INT DEFAULT 0;声明局部变量，再用SELECT COUNT(*) INTO cnt FROM other_table ...（注意：只能查其他表，或用子查询绕过限制） - 如果必须统计本表，改用
(SELECT COUNT(*) FROM orders AS o2 WHERE o2.user_id = NEW.user_id)这种相关子查询，它被允许且不会触发递归限制 - 避免在
AFTER触发器里更新本表，极易死锁或循环触发
PostgreSQL 中 NEW 记录字段无法直接参与 UPDATE？
PostgreSQL 的 BEFORE 触发器函数返回 NEW 时，可以修改其字段值；但很多人误以为 NEW.order_count = (SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id) 就能生效——其实不行，因为 NEW 是只读记录类型，必须用 NEW := NEW #= hstore('order_count', count_val::text)（需启用 hstore）或更稳妥的写法：NEW.order_count := count_val;（前提是 order_count 是表中真实列且类型匹配）。
实操建议：
- 函数体第一行必须写
DECLARE count_val INT;，再用SELECT INTO count_val COUNT(*) FROM ... - 确保
NEW.order_count类型和count_val一致（比如都是INTEGER），否则赋值失败静默忽略 - 不要在触发器里调用写入本表的函数，PostgreSQL 对“触发器内修改本表”检查更严格
SQL Server 触发器里 @@ROWCOUNT 为什么总为 0？
SQL Server 的 AFTER INSERT 触发器中，常有人想用 @@ROWCOUNT 判断本次插入了几行，再批量更新统计表。但实际运行时 @@ROWCOUNT 经常是 0——因为触发器开头任何语句（哪怕只是 DECLARE @x INT）都会重置它。而且，INSERTED 临时表才是唯一可靠的数据源。
实操建议：
- 立刻读取
INSERTED表：SELECT user_id, COUNT(*) AS cnt INTO #tmp FROM INSERTED GROUP BY user_id - 用
MERGE一次性更新统计表，避免循环处理：MERGE stats_table AS t USING #tmp AS s ON t.user_id = s.user_id WHEN MATCHED THEN UPDATE SET order_count += s.cnt WHEN NOT MATCHED THEN INSERT (user_id, order_count) VALUES (s.user_id, s.cnt); - 别在触发器里用
PRINT或RAISERROR调试，它们会干扰@@ROWCOUNT且生产环境必须删掉
触发器自动统计最大的性能陷阱
最隐蔽的问题不是语法，而是**每次 INSERT/UPDATE 都触发全表扫描式 COUNT(*)**。哪怕加了索引，COUNT(*) 在大表上仍是 O(N) 操作。线上单次插入延迟从 2ms 涨到 200ms 很常见。
实操建议：
- 统计字段尽量用
INCREMENT代替COUNT(*)：比如订单表插入时，在触发器里直接NEW.order_count = OLD.order_count + 1（需用户表有该字段且初始值正确） - 高频更新场景改用异步方式：触发器只往消息队列发变更事件，由外部服务聚合后定时回写
- MySQL 5.7+ 可考虑用
GENERATED COLUMN（虚拟列）配合索引加速查询，但不能替代触发器更新逻辑
触发器不是万能计数器，它适合低频、强一致性要求的场景；一旦表行数过百万，先测 COUNT(*) 在最差情况下的耗时，再决定要不要砍掉这个触发器。
