This post isn't going to solve any problems for you It was just something I stumbled on that struck me as funny, while working on a demo for something else. Brent didn't believe it at first, so I thought I'd share with the class. Blog. You, Your Name Here. Hiya! So there I was, creating…
Oh God, he's talking about statistics again Yeah, but this should be less annoying than the other times. And much shorter. You see, I hear grousing. Updating statistics was bringin' us down, man. Harshing our mellow. The statistics would just update, man, and it would take like... Forever, man. Man. But no one would actually…
Confession time This started off with me reading a blurb in the release notes about SQL Server 2016 CTP 3.3. The blurb in question is about statistics. They're so cool! Do they get fragmented? NO! Stop trying to defragment them, you little monkey. Autostats improvements in CTP 3.3 Previously, statistics were automatically recalculated when the…
Here's a handy flowchart for whenever you find yourself worrying about fragmentation:
*Talk to your doctor about whether fragmentation is a problem for you. Seek help for index maintenance lasting longer than four hours. Serious side effects may occur if all index maintenance is ignored completely.
Everybody wants to know about index fragmentation
It is an inescapable vortex of malaise and confusion. Like that swamp in The Neverending Story that killed the horse. Sorry if you haven't seen that movie. The horse wasn't that cool, anyway.
Neither is index fragmentation, but it's not worth losing sleep over. Or a horse.
I found a quirky thing recently While playing with filtered indexes, I noticed something odd. By 'playing with' I mean 'calling them horrible names' and 'admiring the way other platforms implemented them'. I sort of wrote about a similar topic in discussing indexing for windowing functions. It turns out that a recent annoyance could also…
Hey, remember 2005?
What a great year for... not SQL Server. Mirroring was still a Service Pack away, and there was an issue with spinlock contention on OPT_IDX_STATS or SPL_OPT_IDX_STATS. The KB for it is over here, and it's pretty explicit that the issue was fixed in 2008, and didn't carry over to any later versions. For people still on 2005, you had a Trace Flag: 2330.
An interesting question came up in our SQL Server Performance Tuning course in Chicago: when creating an indexed view, does it require an exclusive lock on the underlying table or tables? Let's test it out with a simple indexed view run against a non-production environment. (AKA, a VM on my laptop running SQL Server 2014.)…
Filtered indexes can be tricky. Just getting your queries to use the filtered index can be a real pain. Parameterization may mean it's "unsafe" to use the filtered index. The optimizer might want the filtered column in your key or include column list when it doesn't seem like it should have to be there. The weather might be cloudy.
It's tempting to think that table partitioning will improve query performance. After all, it's an Enterprise Edition feature-- it must have a lot of magic, right? Table partitioning does have magic for the right situations. It shines when you want to add a large amount of data to a table or remove a large amount…
“Throughout history, slow queries are the normal condition of man. Indexes which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people who don't think bit columns are selective enough to…
Clustered indexes are fundamental
And I'm not just saying that because Kendra is my spiritual adviser!
They are not ~a copy~ of the table, they are the table, ordered by the column(s) you choose as the key. It could be one. It could be a few. It could be a GUID! But that's for another time. A long time from now. When I've raised an army, in accordance with ancient prophecy.
i've seen this happen
Especially if you've just inherited a database, or started using a vendor application. This can also be the result of inexperienced developers having free reign over index design.
Unless you're running regular health checks on your indexes with something like our sp_BlitzIndex® tool, you might not catch immediately that you have a heap of HEAPs in your database.
During some testing with SQL Server 2014's new cardinality estimator, I noticed something fun: the new CE can give you different index recommendations than the old one. I'm using the public Stack Overflow database export, and I'm running this Jon Skeet comparison query from Data.StackExchange.com. (Note that it has something a little tricky at the…
It's not glamorous And on your list of things that aren't going fast enough, it's probably pretty low. But you can get some pretty dramatic gains from indexes that cover columns you're performing aggregations on. We'll take a quick walk down demo lane in a moment, using the Stack Overflow database. Query outta nowhere! [crayon-6a6387ceeacbd015680452/]…
Hooray Windowing Functions
They do stuff that used to be hard to do, or took weird self-joins or correlated sub-queries with triangular joins to accomplish. That's when there's a standalone inequality predicate, usually for getting a running total.
It's common to try to build the perfect index for a query. This index only uses the exact right columns for the key columns and other, presentational, data is pushed to the INCLUDE section of the index. While you can create a narrow key this way, the entire index row can become wide.
A Sample Report
Do foreign keys hurt the performance of inserts? Okay, we all know that foreign keys do require some work, but the crazy people of the internet have wildly varying guesses as to just how much work is involved. Estimates varied from "barely any" to "as much as 50% slower". I figured that you were going…
When you create an index in SQL Server with multiple columns, behind the scenes it creates a related multi-column statistic for the index. This statistic gives SQL Server some information about the relationship between the columns that it can use for row estimates when running queries.
But what if you use 'included' columns in the index? Do they get information recorded in the statistics?
Have you ever been watching queries crawl, feeling sort of helpless because you can't change them? And even if you could, it's hitting a new custom column in an ISV table that no one bothered to tell you about. I've been there. I've been pomade deep there.
I've also had my Robot tell me: "there's an index for that, Erik."
