How SQL Server compiles, optimizes, and executes individual queries.
573 associated posts292 primary posts
In the classic spirit of my How to Think Like the Engine class, let's go take a look at the StackOverflow.Users table and find all the users named Brent. There's a DisplayName field, and I'm going to be querying that a lot in this blog post, so I'll go ahead and create an index on it, then look for the Brents:
Forgotten, But Not Gone
Two of the best built-in tools to figure out if your query tuning efforts are headed in the right direction are SET STATISTICS TIME ON and SET STATISTICS IO ON. If you're really fancy, you can use SET STATISTICS TIME, IO ON. By fancy I mean lazy. By lazy I mean efficient. You get the idea. Magic.
Compiles Aren't The Same As Recompiles
If you're seeing high RECOMPILES, this post isn't for you. We'll talk about the differences between compiles and recompiles, but not how to troubleshoot recompiles.
Recompiles mean one of two obvious things: You have a RECOMPILE hint at the stored procedure or statement level, or SQL found a reason that a new query plan had to be compiled, despite the presence of what was once a perfectly good query plan.
This week, Brent, Richie, Tara, and Erik discuss enhancing queries, database corruption, availability groups, parameter sniffing, sending mail via SQL server, whether SQL 2016 is solid or not, other versions of SQL, physical servers vs virtual servers, and much more!
Here’s the video on YouTube:
This is not about table partitioning If you want to learn about that, there's a whole great list of links here, and the Best Blogger Alive has a tremendous post on why table partitioning won't make your queries any faster over here. With that out of the way, let's talk about partitioned views, and then…
One of the most frequent complaints that I hear when presenting to DBAs about Entity Framework is that it's "slow" and that "developers should be endlessly tortured for using it". Ok, the second part I just made up but the sentiment exists. DBAs just don't like developers using Entity Framework and with good reason. Entity Framework can make…
This week, Brent, Richie, and Erik discuss execution plans for table value functions, how to prepare for the Senior DBA course, source control software, generating fragmentation, backups, and the new TV shows the team is looking forward to this season.
Here’s the video on YouTube:
Since the dawn of man, people have struggled with sharing execution plans with each other for performance tuning. Now, it's easy. First, get yourself a plan: Get the estimated execution plan by hitting control-L or clicking Query, Display Estimated Plan. Right-click on the graphical plan, and click View XML. Copy all of that. Or even…
This week, Brent, Richie, Erik, and Tara discuss parameter sniffing, database backups, referential integrity in databases, clustering, creating and using indexes, in-place upgrades, bench marking tools, and more.
Here’s the video on YouTube:
This week, Brent, Richie, and Tara discuss corruption, resetting query stats, fixing parameter sniffing issues, how to suggest features for our scripts, and why Brent is sporting an Oracle sweatshirt.
Here’s the video on YouTube:
Background: a company came to us with a request: they had a lot of smart people who wanted to learn the basics of T-SQL in a day. Could we build an intro-to-T-SQL course that didn't suck? Well, sure - as long as we could give it away free on the site. So here it is:
As part of an experiment, I needed to build a really long query. (Don't ask.)
From another recent experiment, I know that SQL Server won't let a query return more than 65,535 columns. I set about writing a one-line query that would return 65,535. I'm a big fan of writing the simplest reproduction scripts possible - I don't want them to rely on tables if they don't have to - so we'll start a CTE like this:
The most popular way of using sp_BlitzCache® is to just run it - by default, it shows you the top 10 most CPU-intensive queries that have run on your server recently. Plus, it shows you warnings about each of the queries - if they're missing indexes, experiencing parameter sniffing issues, running long, running frequently, doing implicit conversion, you name it.
Great question!
We recently added some columns to sp_BlitzCache to help you remove undesirable plans from the cache. Doing this will force SQL to come up with a new plan, or you know, just re-create the old plan. Because that just happens sometimes. I answered it, but I wasn't happy with my answer. So here's a better one!
When a query is sometimes fast and sometimes slow, for the same input parameters, and you swear nothing else in the environment is changing, that's often a case of parameter sniffing.
After SQL Server starts up and you run a stored procedure, SQL Server builds an execution plan for that proc based on the first set of parameters that are passed in.
When you need to find out why a stored procedure is running slow, here's the information to start gathering: Check to see if the plan is in the cache. Run sp_BlitzCache® and use several different @sort_order parameters - try cpu, reads, duration, executions. If you find it in your top 10 plans, you can view…
Microsoft has been quietly making some amazing improvements for performance tuners in SQL Server 2012, 2014, and 2016. This week, we're going to introduce you to just how awesome they are. (They being the improvements, not Microsoft. You already knew they were awesome.)
Using the freely available StackOverflow database, let's start with a simple query - SELECT * FROM Users:
This comes up during Office Hours once a week Which pretty much gives it a 100% hit rate. I'm writing this mostly to have something to reference when people ask. Trace flags If you restore a database on a SQL Server 2014 or greater instance, you have choices to make. You can either set the…
Here at Brent Ozar Unlimited We have a proud tradition of not blaming index fragmentation for everything. There are points you should deal with it, but they're probably not 5% and 30% and 1000 pages. But that's not what this blog post is about. I'm hoping to clarify why we're more interested in up to…
Using the StackOverflow database, let's check out Krock's query. He's a competitive fella, and he's looking to find users who signed up for StackOverflow after he did, but who have a higher reputation than he does. I'm going to simplify the query a little here: [crayon-6a70d4db06ae0297591235/] The Users table has a clustered index on the Id…
