PostgreSQL高级特性：触发器与规则系统

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

触发器基础：门口自动感应器

梁叔的仓库入口新装了一台自动感应器，只要包裹经过，扫码枪就会自动记录并为包裹贴上一张“易碎品”标签。它不需要仓库员每次手动操作，也不会漏掉任何一个包裹。这个设备的角色，就相当于 PostgreSQL 里的触发器：一种绑定在表上的数据库对象，当 INSERT、UPDATE、DELETE 发生时，数据库自动调用预先写好的函数。

在 PostgreSQL 中，触发器由“事件”和“函数”两部分组成。事件告诉数据库什么时候触发，函数告诉数据库触发后做什么。例如：

这段 SQL 的意思是：每当有包裹要插入 packages 表时，在真正写入之前，逐行执行 add_label() 函数。函数里可以访问 NEW 代表新包裹，也可以访问 OLD 代表被替换的旧包裹，从而实现“放进仓库前先贴标签”的效果。

不过设备不会凭空工作，每次触发都要付出成本。可以用下面的公式估计一个触发器的开销：

梁叔清楚，每多一道自动感应门就多一分等待；一旦包裹批量进仓，感应器的累计开销就不能忽视。所以，理解触发器基础之后，下一步就要看如何选择“什么时候感应、怎样感应”。

CREATE TRIGGER before_insert_pkgBEFORE INSERT ON packagesFOR EACH ROWEXECUTE FUNCTION add_label();

触发时机：出发前检查还是到站后记录

梁叔给仓库定了两条规矩：包裹出发前，必须检查重量并改贴正确标签；包裹到达货架后，再由扫码枪记录到货时间。前一种“出发前改数据”对应 PostgreSQL 的 BEFORE 触发器，后一种“到站后记录”对应 AFTER 触发器。

BEFORE 触发器最大的特点，是可以在行真正写入前修改 NEW 的内容。比如检查到重量超标的包裹时，直接改写它的物流等级。AFTER 触发器则在行写入或更新完成之后执行，适合做审计、通知、汇总，但它不能再回头修改已经写入的数据。此外还有 INSTEAD OF 触发器，专门用在视图上，代替视图上原本无法执行的写入操作，就像客户下单要求“把包裹送到月球”，仓管员就用一套替代流程处理。

触发时机的选择可以用下面的逻辑表示：

梁叔的比喻依然成立：BEFORE 是在包裹出发前动手改货，AFTER 是在包裹入库后记账。选对时机，既能保证数据正确，又能避免无意义的重复劳动。

触发粒度：逐个扫码还是一单扫码

梁叔发现，感应器有两种工作模式：一种是每一个包裹经过都单独扫码，另一种是一整批包裹凭一张出库单统一记录。前者对应 行级触发器，后者对应 语句级触发器。

行级触发器对每一条受影响的数据行执行一次函数，因此可以拿到每一行的 NEW 和 OLD，适合逐行校验和逐行审计。语句级触发器只在整条 SQL 语句执行完毕后触发一次，拿不到逐行的 NEW/OLD，但处理大批量数据时开销低得多。换句话说，同样是一千个包裹，行级感应需要扫一千次码，语句级感应只需要刷一次出库单。

两种粒度的成本关系可以写成：

如果梁叔每次都让感应器逐包扫码，传送带迟早会堵住；只有偶尔需要精确处理每一件包裹时，行级触发器才值得使用。理解了粒度，就能为触发器选择合适的“感应精度”。

规则系统：会改写订单的主管

梁叔的仓库里还有一位主管，手里常年拿着一支红笔。只要看到订单上写着“空运”，他就自动改成“陆运”；看到目的地在冷库区，就顺手加上“需要冷藏”的备注。这个过程发生在包裹发出之前，订单本身被改写了。PostgreSQL 的 规则系统 就是这种机制：它在 SQL 语句真正执行前，把原始查询重写成另一个查询。

规则用 CREATE RULE 创建。例如：

这段规则表示：当有人更新 packages 表里已完成的包裹时，不执行原来的更新，而是把新行插入历史表。与触发器不同，规则不依赖每一行的触发器函数，而是直接在查询解析和重写阶段修改 SQL。正因为如此，规则还能处理触发器做不到的事，比如改写 SELECT 查询，并且经常用于实现可写视图。

一个查询可以被多条规则依次改写，因此最终执行计划可以表示为：

主管会把所有订单先改一遍再下发，规则系统也是如此。它站在“语句层面”工作，所以非常适合做查询重写和历史数据重定向，而不是逐行处理。

CREATE RULE redirect_old ASON UPDATE TO packagesWHERE OLD.status = 'done'DO INSTEAD INSERT INTO packages_history VALUES (NEW.*);

触发器VS规则：各就各位

梁叔常被问到：既然都有自动化能力，为什么还要分两套设备？答案很简单：感应器适合处理“每一件包裹”，主管的红笔适合处理“整张订单”。触发器与规则系统各有分工。

触发器绑定在表上，随着每一行数据的变化而触发，天然适合做逐行校验、审计日志、级联更新。它能访问 NEW/OLD，能参与事务内的细粒度判断。规则系统则在查询开始前改写 SQL，适合把复杂的查询逻辑下沉到数据库层，例如把对视图的查询重写到真实表，或者把更新操作重定向到历史表。

两者的成本模型也可以对比：

梁叔不会让感应器去改写整张订单，也不会让主管去逐个检查包裹。工程上也是如此：审计、完整性校验默认选触发器；视图改写、查询重定向默认选规则系统。

性能调优：让传送带不拥堵

随着订单量暴增，梁叔仓库的传送带开始频繁卡顿。原因很简单：每个包裹都在感应器前做太多额外动作。触发器性能调优的本质，就是减少不必要的“逐包处理”。

常见的优化手段包括：在触发器定义中加 WHEN 条件，让无关包裹直接滑过感应器；大批量操作改用语句级触发器或临时表缓存，只在语句结束后统一处理；把多个简单触发器合并成一个函数，减少重复扫描；用 pg_trigger_depth() 判断递归层级，避免触发器自己调用自己导致死循环。

经过优化后，触发器在批量场景下的平均单行开销可以写成：

梁叔在传送带前装上“分拣器”，把不需要处理的包裹提前分流；数据库里的 WHEN 条件和语句级触发器就是同样的分流器。优化不是让触发器消失，而是让它只在必要的时候才工作。

事务约束：同一本账本

梁叔要求仓库里的所有操作都记在同一本账本上：如果最后一笔记录写错了，前面所有改动都要一起作废。数据库中的触发器也运行在同一个事务里，触发器函数一旦抛出异常，整个事务都可能回滚。这既是安全保证，也是需要小心的风险。

比如在触发器里调用外部短信服务，包裹数据随后回滚，但短信已经发出去了，外部副作用无法撤销。因此，工程上会把“发短信”这类操作写入一张待发送表，真正发送交给外部任务，这样事务回滚时只会回滚待发送记录。

约束触发器是另一种常用工具，它把检查推迟到事务提交前执行。可以用 CREATE CONSTRAINT TRIGGER ... DEFERRABLE INITIALLY DEFERRED 实现。事务能否提交，取决于所有约束条件是否满足：

梁叔的账本逻辑让仓库不会出现半截对不上的记录；在 PostgreSQL 中，事务与约束触发器共同保证数据最终一致。记住：不能只想着“多做事”，还要想着“做错事之后能不能干净地撤销”。

应用模式：从审计台账到数据同步

梁叔经过多年实践，摸索出一套高效用法：出口处放一台自动拍照机，每个包裹离开都拍照留档，这就是审计日志；货架数据一变，前台大屏立即刷新，这就是数据同步；一个订单取消，关联的拣货单自动作废，这就是级联操作。这些都适合用触发器实现。

典型的审计触发器结构是：AFTER 行级触发器把操作类型、用户名、旧值、新值写入审计表。写入审计表可以表示为：

除了审计，还常用触发器做字段自动填充、统计汇总、缓存刷新。使用时要加上递归防护，例如用 pg_trigger_depth() 判断嵌套深度；上线前也要像梁叔试运行新设备一样，在测试库完整演练插入、更新、删除三条链路。自动化能力越强，越需要提前设计好“万一出错怎么办”。

AI 应用场景

Python 演示

class MiniPG:    """极简的 PostgreSQL 触发器/规则语义模拟器。"""     def __init__(self):        self.rows = {}        self.audit = []        self.before_triggers = []        self.after_triggers = []        self.rules = []        self.serial = 0     def add_before_trigger(self, event, fn):        self.before_triggers.append({"event": event, "fn": fn})     def add_after_trigger(self, event, fn):        self.after_triggers.append({"event": event, "fn": fn})     def add_rule(self, event, rewrite):        self.rules.append({"event": event, "rewrite": rewrite})     def apply(self, event, data):        for rule in self.rules:            if rule["event"] == event:                data = rule["rewrite"](data)        old = self.rows.get(data.get("id"))        for t in self.before_triggers:            if t["event"] == event:                data = t["fn"](data)        if event == "INSERT":            self.serial += 1            data["id"] = data.get("id", self.serial)            self.rows[data["id"]] = data        elif event == "UPDATE":            if data.get("id") in self.rows:                self.rows[data["id"]] = {**self.rows[data["id"]], **data}                data = self.rows[data["id"]]        self.audit.append({"event": event, "id": data.get("id"), "row": data})        for t in self.after_triggers:            if t["event"] == event:                t["fn"](data, old)        return data  def fill_default_region(data):    data.setdefault("region", "default")    return data  def set_vip(data):    data["level"] = "vip"    return data  def write_audit(data, old=None):    print("AFTER:", data.get("id"), data.get("level"), "old=", old)  if __name__ == "__main__":    db = MiniPG()    db.add_rule("INSERT", fill_default_region)    db.add_before_trigger("INSERT", set_vip)    db.add_after_trigger("INSERT", write_audit)    db.apply("INSERT", {"id": 101, "name": "robot"})    db.apply("INSERT", {"name": "sensor"})    print("rows:", db.rows)    print("audit_count:", len(db.audit))

1. self.before_triggers.append({"event": event, "fn": fn})注册一个 BEFORE 触发器，相当于在仓库入口安装自动感应器。
2. for rule in self.rules:在触发器和写入之前遍历规则，模拟 PostgreSQL 的查询重写阶段。
3. data = rule["rewrite"](data)规则函数接收原始数据并返回改写后的数据，就像主管在订单上改字。
4. for t in self.before_triggers:在真正写入前执行所有 BEFORE 触发器，允许修改包裹内容。
5. self.audit.append({"event": event, "id": data.get("id"), "row": data})保存审计记录，模拟 AFTER 触发器的核心用途。
6. db.add_rule("INSERT", fill_default_region)注册一条规则：插入时自动补全地区字段。
7. db.add_before_trigger("INSERT", set_vip)注册 BEFORE 触发器：插入前把包裹标记为 VIP。
8. db.add_after_trigger("INSERT", write_audit)注册 AFTER 触发器：插入后打印审计日志。

常见误区

面试题