小编OMG*_*ies的帖子

我遇到了两种选择的情况：

1. 使用成本约为 0.07 的单个查询

   INSERT INTO @vals
   SELECT ...
     FROM ...
     JOIN ... 
     JOIN ...
    WHERE a.col = 1 OR b.col IS NOT NULL
   

   Run Code Online (Sandbox Code Playgroud)

2. 使用两个查询得到相同的结果——第一个成本 ~0.05，第二个成本 ~0.3

   INSERT INTO @temp
   SELECT ...
     FROM ...
     JOIN ...
   
   INSERT INTO @vals
   SELECT ...
     FROM @temp
     JOIN ...
    WHERE a.col = 1
   UNION ALL
   SELECT ...
     FROM @temp
     JOIN ...
     JOIN ...
    WHERE b.col IS NOT NULL
   

   Run Code Online (Sandbox Code Playgroud)

我选择了第一个选项 - 单个查询，因此不必担心在查询之间更改数据并降低总体成本。这是谨慎的选择吗？

这是针对最初需要约 5 分钟以上的操作，在我们的应用程序中超时。使用具有唯一聚集索引的表变量，重写使该时间始终缩短到 1.5 分钟。

我们最近进行了更改，以根据以前在存储过程中使用的逻辑创建约束，其中一部分包括使用INSTEAD OF触发器来集中逻辑。

逻辑通常很简单：

1. 存储过程包含针对视图的 INSERT（或 UPDATE）语句，该视图具有 INSTEAD OF INSERT/UPDATE 触发器
2. 触发器包含实际的逻辑——通常是两条语句，处理一条记录到主表和一个（或多个）支持表（包括参照完整性）的插入/更新。

问题是当触发器中的语句中遇到类似 CHECK 约束的东西时。事务被转储，一切都被回滚。我正在考虑必须在有问题的存储过程中复制 CHECK/etc 约束以在触发器执行之前进行验证——还有其他选择吗？