Comments on: Ultimate query tuning

By: Ian Stirk

Ian Stirk — Fri, 30 Aug 2013 13:51:42 +0000

Great post, a very useful and smart algorithm…
Ian

By: Rob Farley

Rob Farley — Sun, 25 Aug 2013 17:07:30 +0000

Yes – I see a lot of potential around filtered indexes. They also help if you have a fixed inequality predicate and want the data ordered by something else. So much potential…

By: TheSQLGuru

TheSQLGuru — Sat, 24 Aug 2013 20:37:06 +0000

Another great opportunity for filtered indexes is where you have large data skew. You can get the right query plan both ways (either scans/hashes for the skew(ed) values or seeks/nested loops for onesy-twosy values) with indexes that are a fraction of the normal index size.

By: Rob Farley

Rob Farley — Sat, 24 Aug 2013 12:59:09 +0000

Hi David,
This example was inspired by some tuning I did for a client a while back. The filter was looking for rows that met a particular condition, because things in that condition needed attention. Once they had been seen to, the condition wasn’t true any more, so the filtered index returned to being empty.
Another scenario could be to have a "Payment Pending" situation. Most people pay straight away, but occasionally you might have something which enters a special "needs attention" state for a short while.
Does that help?
Rob

By: David Howell

David Howell — Sat, 24 Aug 2013 12:43:59 +0000

I can see lots of usage scenarios for this, thanks for the easy to follow example.
I didn’t get what you mean by this part "For the real scenario, that row gets picked up and removed quite quickly, returning the query to the ‘zero reads’ scenario."
In the real scenario where you are looking for order quantity > 1200, why would a row in the index be removed in the query? I think I am just reading that wrong, could you explain it simply?

By: Rob Farley

Rob Farley — Fri, 23 Aug 2013 10:11:24 +0000

Indeed! The same applies for ANSI_NULLS, which must be ON. There are actually a bunch of things that require those settings, and apparently one day SQL will refuse connections which don’t have those settings configured properly.

By: ALZDBA

ALZDBA — Fri, 23 Aug 2013 10:03:20 +0000

Great post, Rob. I just feel the need to emphasize the needed SET options when working with filtered indexes, as these settings a mandatory for all connections hitting that table. So not only at create time of the index ! ( bol/technet weren't clear on this : http://technet.microsoft.com/en-us/library/ms188783.aspx ) Been bit by it once ( on a production system after dev/QA worked fine but apparently not all apps had been tested ). "UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. " This blog helped me diagnose and solve the issue: http://akashonly.blogspot.be/2012/01/filtered-index-and-quotedidentifier.html

By: John Hennesey

John Hennesey — Thu, 22 Aug 2013 23:45:11 +0000

I agree with Andre – the light bulb just turned on! I haven’t seen it presented in such a manner that makes such sense. Thanks!

By: Rob Farley

Rob Farley — Thu, 22 Aug 2013 00:55:01 +0000

Jack – yes, that’s a useful benefit too.
pmbAustin – Indexes shouldn’t change the results of a query. If an index doesn’t provide sufficient coverage of the table to satisfy a query, the SQL engine won’t pretend it does. A filter like IsActive=1 will only be used for queries that include an IsActive=1 predicate.

By: pmbAustin

pmbAustin — Thu, 22 Aug 2013 00:19:28 +0000

Based on your other blog entry… is there potential for a filtered index like this to "break" queries, by changing the data they return? If you do 80% of your queries for "IsActive=1", but the other 20% on all rows, will the filtered index cause any danger of it being used when looking at all rows? Is there a "best practice" for doing things like creating two indexes, one filtered one not, so the optimizer has the best index to choose in each case?