2

I've got a table of addresses that I'm replicating. There are 14 different types of addresses available. In order to cut down on the replicated data, I'm filtering on the AddressType field. The field is an int, and has a value of 1 to 14. I originally had a filter of 

AddressType = 2

, as I was only interested in addresses with that type. However, a recent change requires I have both AddressType 1 and 2 replicated. I at first changed the filter to 

AddressType in (1,2)

Would I be better off with a filter of 

AddressType < 3

Thoughts?

4

4 に答える 4

5

There can be a significant difference as the numbers get larger. You won't see a performance difference at the smaller numbers but you will see a difference as it gets larger, especially if there is an index on AddressType. Your IN () version essentially gets translated to:

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

I do agree with the others for this specific case. (1) the performance difference when there are only 14 values is unlikely to be noticeable. (2) Jonathan's point that IN () more accurately reflects what you want to do is a good one, also.

But for future readers who maybe have a lot more possible values, I think it's important to note how things can change when the list is not so limited (or when < and IN () no longer offer the same functionality, e.g. when an address type changes). At larger sizes even when there is the convenience that everything in the IN () list matches a range criterion, there are still other things to consider: (1) it is less convenient to type IN (1,2,3,4,5,6,7,8,9,10, ...) and this also can lead to a much larger batch size when we're talking about extremes.

于 2012-07-18T15:05:16.043 に答える
4

When your requirements change and you need types 1, 2, 9 and 14, the IN formulation will be better. The list comparison more accurately reflects what you are doing (choosing two types from a small list of possible values).

The less than notation happens to work, but it is coincidental that the representation of the types is susceptible to range comparisons like that.

In terms of performance, there is essentially nothing to choose between the two. The less than operation will perhaps be marginally quicker, but the margin is unlikely to be measurable.

于 2012-07-18T15:06:01.823 に答える
1

Execution plans look identical. I'm inclined to say you should go with IN in case you need to add another address type like "5" that will force you to rewrite the < query. IN is a lot more extensible because it doesnt matter what you add to it.

于 2012-07-18T15:05:25.227 に答える
-3

すべての答えは大丈夫です...他のポスターと同じように...違いを生むかもしれないその「他に何をするかもしれない」。

したがって、比較では常にNULLを考慮してください。記述されているとおり、クエリはNULLで問題ありませんが、NULLが可能である場合...そしてSQLをアドホックに変更または再利用する場合は、それを否定します...INではなく比較に問題がある可能性があります。

たとえば、NOT IN（1,2）は、vs> =3...または使用する可能性のあるあらゆる化身に対してどのように実行されますか。NULLは、最初はTRUEですが、2番目はFALSEです。（NULLSは比較です）。

NULLSを検討することは、SQLの作成に息を吹き込むようなものです。

于 2012-07-18T15:19:23.020 に答える