💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
# 38.7\. 规则与触发器的比较 许多用触发器可以干的事情同样也可以用PostgreSQL规则系统来实现。 目前不能用规则来实现的东西之一是某些约束,特别是外键。 可能在某字段的值没有在另一个表里出现的情况下用一条有条件的规则把查询重写为`NOTHING`。 不过这样做数据就会被不声不响的扔掉,因而这也不是一个好主意。如果需要检查有效的值, 而且如果是无效值出现时要生成一个错误信息,这种情况下要用触发器来做。 在本节中,我们专注于使用规则更新视图。本节中的所有更新规则的示例也可以使用在视图上的 `INSTEAD OF`触发器实现。编写这样的触发器通常比编写规则要容易, 尤其是需要复杂的逻辑执行更新时。 对于两者都可用的情况,哪个更好取决于对数据库的使用。触发器为每个涉及到的行执行一次。 规则修改查询或生成额外的查询。所以如果在一个语句中涉及到多行, 一个生成额外查询的规则通常可能会比一个对每一行都分别执行一次(而且要重新决定做什么很多次) 的触发器快一些。不过,触发器的方法从概念上要远比规则的方法简单,并且很容易让新手可以做正确事情。 下面展示一个在同一个情况下选择规则与触发器的对比例子。例如这里有两个表: ``` CREATE TABLE computer ( hostname text, -- 已索引 manufacturer text -- 已索引 ); CREATE TABLE software ( software text, -- 已索引 hostname text -- 已索引 ); ``` 两个表都有好几千行,并且`hostname`上的索引是唯一的。规则/触发器应该实现这样一个约束, 这个约束从`software`表中删除引用已删除计算机的行。触发器可以用下面这条命令: ``` DELETE FROM software WHERE hostname = $1; ``` 因为触发器是为从`computer`里面删除的每一个独立的行调用一次, 那么它可以准备并且保存这个命令的规划,把`hostname`作为参数传递。 规则应该这样写: ``` CREATE RULE computer_del AS ON DELETE TO computer DO DELETE FROM software WHERE hostname = OLD.hostname; ``` 现在看看这两种不同的删除。在下面情况: ``` DELETE FROM computer WHERE hostname = 'mypc.local.net'; ``` 对表`computer`使用索引(快速)进行扫描并且由触发器声明的查询也用索引进行扫描(同样快速)。 规则里多出来的查询是一个: ``` DELETE FROM software WHERE computer.hostname = 'mypc.local.net' AND software.hostname = computer.hostname; ``` 因为已经建立了合适的索引,规划器将创建一个下面的规划 ``` Nestloop -> Index Scan using comp_hostidx on computer -> Index Scan using soft_hostidx on software ``` 所以在规则和触发器的实现之间没有太多的速度差别。 下面的删除希望删掉所有 2000 个`hostname`以`old`开头的计算机(记录)。 有两个可能的用于这个用途的查询。一个是: ``` DELETE FROM computer WHERE hostname >= 'old' AND hostname < 'ole' ``` 规则增加的命令是: ``` DELETE FROM software WHERE computer.hostname >= 'old' AND computer.hostname < 'ole' AND software.hostname = computer.hostname; ``` 查询的规划将会是 ``` Hash Join -> Seq Scan on software -> Hash -> Index Scan using comp_hostidx on computer ``` 另一个可能的查询是: ``` DELETE FROM computer WHERE hostname ~ '^old'; ``` 它由规则增加执行规划是: ``` Nestloop -> Index Scan using comp_hostidx on computer -> Index Scan using soft_hostidx on software ``` 这表明,规划器不能认识到表`computer`里的`hostname` 的条件在多个条件表达式以`AND`的方式组合在一起时同样可以用于`software`上的索引扫描, 就像在用正则表达式的查询里一样。触发器将在任何 2000 个要被删除的旧计算机里被调用一次, 结果是对`computer`的一次索引扫描和对`software`的 2000 次索引扫描。 规则的实现将会使用两个使用索引的命令来完成。所以`software` 表的实际大小决定了规则进行顺序扫描后是否仍然更快。即使所有要使用的索引块都很快在缓冲里出现, 执行 2000 个在 SPI 管理器上的查询仍然要花不少时间。 我们要看的最后一个查询是: ``` DELETE FROM computer WHERE manufacturer = 'bim'; ``` 同样,这也会导致从`computer`表里删除多行。 所以触发器同样会向执行器提交很多查询。规则生成的命令将会是: ``` DELETE FROM software WHERE computer.manufacturer = 'bim' AND software.hostname = computer.hostname; ``` 但规则规划又将是对两个索引扫描的嵌套循环。不过使用了`computer`的另外一个索引: ``` Nestloop -> Index Scan using comp_manufidx on computer -> Index Scan using soft_hostidx on software ``` 在任何一种情况下,从规则系统出来的额外查询都或多或少与查询中涉及到的行数量相对独立。 概括来说,规则只是在它们的动作生成了又大又烂的条件连接时才比触发器有较大速度差异, 这时规划器将失效。