2

我有一个要复制的地址表。有 14 种不同类型的地址可用。为了减少复制的数据，我在 AddressType 字段上进行过滤。该字段是一个 int，其值为 1 到 14。我最初有一个过滤器

AddressType = 2

，因为我只对这种类型的地址感兴趣。但是，最近的更改要求我复制了 AddressType 1 和 2。我首先将过滤器更改为

AddressType in (1,2)

使用过滤器会更好吗

AddressType < 3

想法？

4

4 回答 4

5

随着数字变大，可能会有显着差异。您不会在较小的数字上看到性能差异，但随着数字变大您会看到差异，尤其是在 AddressType 上有索引的情况下。您的IN ()版本基本上被翻译成：

WHERE AddressType = 1
   OR AddressType = 2
   OR ...

对于这个具体案例，我同意其他人的看法。(1) 只有 14 个值时的性能差异不太可能引起注意。(2) 乔纳森的观点IN ()更准确地反映了你想做的事情，这也是一个好观点。

但是对于可能有更多可能值的未来读者，我认为重要的是要注意当列表不受限制时（或者何时不再提供相同的功能，例如当地址类型发生变化时）事情会如何变化。在更大的尺寸下，即使列表中的所有内容都符合范围标准很方便，还有其他事情需要考虑：（1）打字不太方便，这也可能导致更大的批量大小，当我们'再谈极端。<IN ()IN ()IN (1,2,3,4,5,6,7,8,9,10, ...)

于 2012-07-18T15:05:16.043 回答
4

当您的要求发生变化并且需要类型 1、2、9 和 14 时，IN 配方会更好。列表比较更准确地反映了您在做什么（从可能值的小列表中选择两种类型）。

小于符号恰好起作用，但巧合的是，类型的表示容易受到这样的范围比较的影响。

在性能方面，两者之间基本上没有什么可以选择的。小于操作可能会稍微快一些，但幅度不太可能是可测量的。

于 2012-07-18T15:06:01.823 回答
1

执行计划看起来相同。我倾向于说你应该使用 IN 以防你需要添加另一个地址类型，如“5”，这将迫使你重写 < 查询。IN 的可扩展性更高，因为添加什么内容并不重要。

于 2012-07-18T15:05:25.227 回答
-3

所有答案都很好......与其他海报一样......它的“你还可以做什么”可能会有所作为。

因此，在任何比较中始终考虑 NULL。您的查询可以写成 NULLS，但是：如果可能有空值...并且如果您决定更改或重用 SQL ad hoc 说，否定它...您可能会遇到比较问题，而不是 IN。

例如 NOT IN (1,2) 如何执行 vs >= 3 ...或者我们可能使用的任何化身。NULL 在第一个中为 TRUE，但在第二个中为 FALSE。（NULLS 是比较）。

考虑 NULLS 应该就像在 SQL 创建中呼吸一样。

于 2012-07-18T15:19:23.020 回答