我有一张我正在复制的地址表。有14种不同类型的地址可供使用。为了减少复制的数据，我在AddressType字段上进行过滤。该字段是一个int，其值为1到14.我最初有一个
的过滤器AddressType = 2
，因为我只对那种类型的地址感兴趣。但是，最近的更改要求我同时复制AddressType 1和2。我首先将过滤器更改为
AddressType in (1,2)
使用
过滤器会更好吗？AddressType < 3
思考？
答案 0 :(得分：5)
随着数字变大，可能会有显着差异。您不会在较小的数字上看到性能差异，但随着它变大，您会看到差异，特别是如果AddressType上有索引。您的IN ()版本基本上会被翻译为：
WHERE AddressType = 1
OR AddressType = 2
OR ...
我同意其他人的具体案例。 （1）当只有14个值时的性能差异不太可能引人注意。 （2）乔纳森认为IN ()更准确地反映出你想要做的事情也是一个好的。
但是对于可能拥有更多可能值的未来读者，我认为重要的是要注意当列表不受限制时（<{1}}和{{}}时， 可以更改的内容{1}}不再提供相同的功能，例如，当地址类型更改时）。即使在<列表中的所有内容都符合范围标准的便利性时，也可以考虑更大的尺寸：还有其他事项需要考虑：（1）键入IN ()不太方便，这也可以当我们谈论极端时，会导致更大的批量。
答案 1 :(得分：4)
当您的要求发生变化并且您需要类型1,2,9和14时，IN配方会更好。列表比较更准确地反映了您正在做的事情（从一小部分可能的值中选择两种类型）。
小于符号恰好起作用，但巧合的是类型的表示容易受到类似范围的比较。
就性能而言，两者之间基本上没有任何选择。不太可能的操作可能会稍微快一点，但边际不太可能是可测量的。
答案 2 :(得分：1)
执行计划看起来完全相同。我倾向于说你应该使用IN，以防你需要添加另一个类似“5”的地址类型，它会强制你重写＆lt;查询。 IN更具有可扩展性，因为它与您添加的内容无关。
答案 3 :(得分：-3)
所有答案都很好......和其他海报一样......它还有“你可能会做什么”，这可能会有所作为。
所以在任何比较中总是考虑NULL。您的查询很好，如同编写的NULLS，但是：IF空值是可能的......如果您决定更改或重复使用SQL ad hoc来说，否定它...您可能会遇到比较而不是IN的问题。
例如，如何不IN（1,2）执行vs＆gt; = 3 ...或我们可能使用的任何化身。 NULL在第一个中为TRUE，在第二个中为FALSE。 （NULLS是比较）。
考虑NULLS应该像呼吸SQL创建一样。