sum()对全null行返回null而非0，导致not null字段写入失败；应使用coalesce(amount,0)预处理或设字段default 0。
触发器更新汇总表时，为什么 SUM() 结果总为 NULL？
常见原因是被聚合字段本身含 NULL，而 SUM() 遇到全 NULL 行会返回 NULL，不是 0。汇总表里对应字段若定义为 NOT NULL，就会报错或写入失败。
解决办法是显式处理空值：
- 在触发器的
SELECT SUM(COALESCE(amount, 0))中包裹COALESCE - 或在汇总表建表时设默认值：
total_amount DECIMAL(10,2) DEFAULT 0 - 避免用
IFNULL（MySQL）或ISNULL（SQL Server）混用——不同数据库函数名不兼容
INSERT/UPDATE/DELETE 触发器该分别写几条？
不能只写一个 AFTER INSERT 就以为覆盖所有场景。汇总逻辑对三类操作的响应完全不同：
-
INSERT：新行加入，需给汇总表对应分组的total_amount加上新值 -
UPDATE：要判断WHERE子句是否影响分组键（如category_id），若变了，就得从旧分组减、往新分组加 -
DELETE：直接从对应分组减去被删行的值
漏掉 UPDATE 的分组变更逻辑，是最常见的数据不一致根源。
触发器里能直接 SELECT 汇总表再 UPDATE 吗？
可以，但必须加事务控制，否则并发写入会出错。例如两个同时插入同 category 的事务，都读到当前 total 是 100，各自加 20，最终写入 120 而非 140。
安全做法是用原子更新：
UPDATE summary_table SET total_amount = total_amount + NEW.amount WHERE category_id = NEW.category_id;
注意：NEW.amount 和 NEW.category_id 是 MySQL 语法；PostgreSQL 用 NEW.amount 相同，但 SQL Server 用 INSERTED.amount ——别硬套。
触发器性能差，有没有更稳的替代方案？
有，但要看场景。触发器在高并发写入时容易成为瓶颈，尤其汇总表被频繁读取时，锁竞争明显。
- 异步方案：业务层写明细后发消息，由消费者更新汇总表（如 Kafka + Python worker）
- 物化视图：PostgreSQL 9.3+ 支持
REFRESH MATERIALIZED VIEW CONCURRENTLY，Oracle 有类似机制 - 定时补算：用
INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）或MERGE（SQL Server）每 5 分钟批量重算一次
触发器不是银弹——它适合低频、强一致性要求的场景；一旦日增明细超 10 万行，就得考虑切换路径。
