触发器不能直接调用报表计算函数，应仅插入重算任务到队列表；下游调度器通过LISTEN/NOTIFY实时消费任务，报表服务需幂等写入并校验版本以保证一致性。
触发器里不能直接调用报表计算函数
SQL 触发器（比如 BEFORE UPDATE 或 AFTER UPDATE）运行在数据库事务上下文中，它不支持执行外部程序、发起 HTTP 请求、写文件或调用应用层逻辑。你不能在触发器里直接写 CALL generate_daily_report() 这类依赖业务代码的调用——除非这个函数是纯 SQL 实现且定义在数据库内（如 PostgreSQL 的 PL/pgSQL 函数），但绝大多数报表逻辑涉及聚合、多表关联、缓存更新、异步通知等，超出 SQL 能力边界。
强行把报表逻辑塞进触发器会导致：
– 事务变长，阻塞写操作
– 报表出错导致主业务更新失败（违反“逻辑解耦”初衷）
– 难以调试和监控，日志分散在 DB 日志中
用触发器写入“重算任务队列”才是合理做法
真正解耦的方式，是让触发器只做一件事：记录“哪里变了、什么时候变的、需要重算什么”。典型做法是向一张轻量级任务表插入记录，比如：
CREATE TABLE report_recalc_queue ( id SERIAL PRIMARY KEY, report_code VARCHAR(50) NOT NULL, target_id BIGINT, -- 如 order_id / user_id created_at TIMESTAMP DEFAULT NOW() );
然后在 AFTER UPDATE 触发器中插入任务：
CREATE OR REPLACE FUNCTION queue_order_recalc()
RETURNS TRIGGER AS $$
BEGIN
IF OLD.status != NEW.status AND NEW.status IN ('shipped', 'cancelled') THEN
INSERT INTO report_recalc_queue (report_code, target_id)
VALUES ('daily_sales_by_region', NEW.order_id);
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;关键点：
– 只判断明确的业务信号（如状态变更），避免全字段比对
– report_code 用于下游调度器识别处理逻辑
– 不写具体 SQL 计算，不碰报表结果表
下游调度器要轮询还是监听？选后者更实时
轮询（比如每 5 秒查一次 report_recalc_queue）简单但有延迟；推荐用数据库原生通知机制，例如 PostgreSQL 的 LISTEN/NOTIFY：
在触发器末尾加一句：
PERFORM pg_notify('recalc_queue_inserted',
json_build_object('report_code', 'daily_sales_by_region',
'target_id', NEW.order_id)::text);应用服务启动后 LISTEN recalc_queue_inserted，收到消息立即拉取对应任务并执行报表计算。好处：
– 零延迟感知变更
– 无空转查询压力
– 天然支持多实例负载分发（每个实例监听同一 channel，靠应用层去重或分片）
MySQL 用户可改用 INSERT ... ON DUPLICATE KEY UPDATE + 应用层长连接轮询，或接入 Canal 解析 binlog——但本质仍是把“通知”和“执行”拆开。
报表结果表必须支持幂等写入和版本控制
因为任务可能重复投递（网络重试、消费者崩溃重启）、或多个触发事件指向同一份报表（比如同一订单多次发货），报表计算服务必须能安全重入：
-
INSERT ... ON CONFLICT (report_date, region) DO UPDATE SET ...（PostgreSQL） - 结果表带
updated_at和version字段，每次写入校验时间戳或乐观锁 - 计算前先查当前最新快照，避免用过期中间态数据覆盖新结果
别省略这步——否则你会发现某天凌晨三点的报表被下午两点的一次误操作覆盖了，而且没日志可追溯。
真正的解耦不在“谁发起”，而在“谁负责兜底、谁保证一致、谁暴露失败”。触发器只是信使，不是工人。
