[dba-SQLServer] Processing diverse where clauses

Arthur Fuller fuller.artful at gmail.com
Wed May 16 07:09:54 CDT 2007


INs are bad policy, typically, unless you have a very small number of
targets. I wrote about this problem at TechRepublic a while ago. I may not
have the article handy, but you can probably find it there. Go to
www.techrepublic.com and search for "Arthur Fuller IN()". That might work.
Else just search for my name and then browse.

Anyway, the article concerns a better way to do the IN part. The problem
with IN is that it almost always forces a table-scan, which in your case
will give you enough time to move to another country and back before it's
done. The article shows how to construct a temp-table from the IN clause and
then do a join to the actual table using the temp table. Especially when
your IN clause could have lots of values, this approach is way faster.

I'll dig now for the article, but I'm fairly certain that it was one of the
things wiped out when I lost a hard disk a month ago or so. If I find it
I'll send it off-list.

Arthur


On 5/15/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I am processing a query where a set of N fields have any value, AND one
> specific field has an IN() clause, i.e. a ton of codes possible.
>
> Is it more efficient to build up a pair of queries, SELECT PKID from tblX
> WHERE FldA in('A','B'...), and another query where the "OR" fields are
> gathered?  Or just use one big query?  I hate to even press the
> button...  I
> am having to test with a TOP 100 kind of thing as it is.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



More information about the dba-SQLServer mailing list