能用但有严格限制：MySQL触发器中禁止读写正在被触发的表，需用NEW/OLD值计算；PostgreSQL可用ON CONFLICT简化，但复杂聚合仍需触发器；事务回滚会同步撤销统计变更，SQLite在WAL模式下易死锁。
MySQL 触发器里不能用 INSERT ... SELECT 直接更新汇总表？
能用，但容易踩坑：如果 SELECT 查询依赖当前正在修改的主表（比如在 BEFORE INSERT 里查同一张表），会报错 ERROR 1442: Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。本质是 MySQL 禁止在触发器中读写“正在被触发的表”。
- 改用聚合计算逻辑，别查原表——比如新增订单时，直接用
NEW.amount累加，而不是SELECT SUM(amount) FROM orders -
AFTER INSERT/AFTER DELETE比BEFORE更安全，但依然不能查本表；AFTER UPDATE要同时处理OLD.amount和NEW.amount的差值 - 汇总表字段必须有唯一约束（如
stat_date+category联合主键），否则INSERT ... ON DUPLICATE KEY UPDATE会失效
PostgreSQL 的 INSERT ... ON CONFLICT 能替代触发器吗？
可以简化逻辑，但不能完全替代：它适合“写入主表时顺带更新统计”，前提是统计维度能从插入行直接推导（比如按天统计，且每行带 created_at）。一旦涉及跨多行聚合（如“每个用户最新 3 条订单平均金额”），还是得靠触发器或应用层维护。
- 用
ON CONFLICT (stat_date) DO UPDATE SET total = total + EXCLUDED.amount，注意EXCLUDED是 PostgreSQL 特有关键字，不是变量名 - 如果统计逻辑含条件判断（如只统计
status = 'paid'的订单），触发器里仍需IF NEW.status = 'paid' THEN ...，ON CONFLICT本身不支持 WHERE - 性能上，触发器比
ON CONFLICT多一次函数调用开销，但差异通常可忽略；高并发下二者都可能成为瓶颈，需配合索引和批量写入优化
触发器更新汇总表时，事务回滚会同步撤销统计变更吗？
会，只要触发器和主表操作在同一个事务里——这是最常被忽略的前提。MySQL 和 PostgreSQL 都保证触发器内 DML 与外层语句原子性一致。
- 但如果你在触发器里调用了外部 HTTP 请求、写文件、或执行
COMMIT（MySQL 存储过程允许但极其危险），就破坏了事务边界，统计值可能残留脏数据 - 测试方法很简单：手动
START TRANSACTION，执行一条会触发统计更新的操作，然后ROLLBACK，立刻查汇总表——值必须回到原样 - 某些 ORM（如 Django）默认禁用自动提交，但显式调用
transaction.atomic()外层包裹时，触发器仍生效；反之，若 ORM 配置了AUTOCOMMIT=True，单条 SQL 就是独立事务，触发器也只属于那个事务
SQLite 支持触发器维护汇总表，但有个硬限制
SQLite 允许触发器，但不支持在触发器中执行 UPDATE 或 INSERT 到“同一数据库中其他表”以外的目标——听起来没问题？问题出在 WAL 模式下：PRAGMA journal_mode = WAL 时，触发器内的写操作可能因锁机制导致死锁，尤其当多个连接同时修改主表。
- 简单场景下关掉 WAL（
PRAGMA journal_mode = DELETE）能绕过，但牺牲并发写性能 - 更稳妥的做法：把汇总逻辑移到应用层，用
INSERT ... RETURNING（SQLite 3.35+）拿到新行 ID 或值，再单独发一条UPDATE summary SET count = count + 1 - SQLite 触发器不支持
FOR EACH STATEMENT，只有FOR EACH ROW，所以批量导入时会逐行触发，速度明显慢于单条聚合 SQL
