SQL Server是否计算后续被丢弃的结果？为何出现无触发行的除零错误？

这是个很典型的查询优化器执行计划相关问题，我来帮你理清楚背后的原因：

核心原因：查询优化器的执行顺序不总是按逻辑书写顺序来 #

咱们先明确：SQL Server完全可能在WHERE过滤之前计算表达式。查询优化器是个“聪明但务实”的家伙，它的目标是用最高效的方式拿到结果，会根据表的统计信息、数据分布、硬件配置（比如你这里的8核虚拟机）来选择执行计划，而不是严格按照你写SQL的逻辑顺序（先过滤、再关联、再计算）。

当启用并行查询时，这个问题会被放大：

• 并行执行时，SQL Server会把数据拆分成多个分片，交给不同的线程并行处理。
• 某个线程可能先处理了原本会被WHERE条件过滤掉的行（也就是不在你指定日期范围内的行），并且提前计算了FT.Value1 / FT.Value2——如果这些被提前处理的行里有Value2=0的情况，就会触发除零错误，哪怕这些行最终不会出现在结果集里。

为什么错误时有时无？ #

这和查询优化器生成的执行计划直接相关：

• 当表的数据量、统计信息发生变化（增删改操作后），查询优化器会重新评估执行计划，可能选择串行执行，或者调整了过滤、计算、关联的顺序，这时候就不会触发错误了。
• 一旦某个并行执行计划被选中，且刚好命中了包含Value2=0的分片（这些分片的行原本会被过滤，但被提前计算了），错误就会稳定复现。

验证与解决建议 #

验证方法 #

1. 查看执行计划：找到Compute Scalar运算符，看它的位置是否在Filter（WHERE过滤）或Join运算符之前——如果是，就说明计算确实先于过滤了。
2. 临时禁用并行：在查询末尾加OPTION (MAXDOP 1)，如果错误消失，就可以确认是并行执行导致的问题。

解决方案 #

你已经用的NULLIF(FT.Value2, 0)是非常稳妥的方法，它能确保分母不会为0。除此之外还可以：

• 用CASE WHEN FT.Value2 <> 0 THEN FT.Value1 / FT.Value2 ELSE NULL END替代，逻辑更直观，同样能避免除零；
• 更新表的统计信息：执行UPDATE STATISTICS PrimaryTable和UPDATE STATISTICS ForeignTable，让查询优化器获得更准确的数据分布，从而选择更合理的执行计划；
• 必要时可以通过查询提示调整并行度（比如OPTION (MAXDOP 4)），但不推荐直接禁用并行，毕竟并行能提升大数据量查询的性能。

内容的提问来源于stack exchange，提问作者Adwaenyth