When your SQL Server database is set to have its statistics automatically updated, you will probably conclude that, whenever the distribution statistics are out-of-date, they will be updated before the next query is executed against that index or table. Curiously, this isn't always the case. What actually happens is that the statistics only gets updated if needed by the query optimiser to determine an effective query plan.… Read more
How often do you check your query plans during development to see if they contain any warnings? If you're missing them, it means that you're not getting all those hints about missing indexes, join predicates or statistics. Is the query optimiser trying to tell you about implicit conversions? Dennes shows how to view the warnings in plan cache for a particular database using SQL… Read more
Normally, the query Optimiser won't consider 'bushy' plans, where both operands to a join operator could be intermediate results from other joins. This means that it won't produce good query plans for some types of query. Hints, by themselves won't do it. More powerful magic is required.… Read more
SQL Server's Query optimiser judges the best query plan from the data in the relevant tables and the server's hardware. How, then, can you investigate the query plans being generated for slow-running queries on a customer's production server when you can neither access the server, nor recreate the database from a backup?… Read more
SQL Server's Query Optimiser relies on statistics for providing a decent query plan. If the statistics are wrong, outdated or missing then you have little realistic hope of having queries that perform well. It is therefore important to appreciate how SQL Server maintains distribution statistics.… Read more
The Query Optimiser needs a good estimate of the number of rows likely to be returned by each physical operator in order to select the best query plan from the most likely alternatives. Sometimes these estimates can go so wildly wrong as to result in a very slow query. Joe Sack shows how it can happen with SQL Queries on a data warehouse with a star schema.… Read more
It comes as rather a shock to find out that one of the commonest circumstances in an OLTP database, an ascending primary key with most querying on the latest records, can throw the judgement of the Query Optimiser to the extent that perfomance nose-dives. Fabiano once again puts on snorkel and goggles to explore the murky depths of execution plans to find out why. … Read more
Fabiano was asked a couple of questions about SQL Server Distribution Statistics. Having given an answer based on his current knowledge, he then decided to find out for himself whether what he'd said was right, and started an epic journey of exploration into Distribution Statistics and the way that the Query Optimiser uses them.… Read more
When Fabiano agreed to undertake the epic task of describing each showplan operator, none of us quite predicted the interesting ways that the series helps to understand how the query optimiser works. With the Merge Interval, Fabiano comes up with some insights about the way that the Query optimiser handles overlapping ranges efficiently… Read more
Did you ever wonder how and why your indexes affect the performance of joins? Once you've read Fabiano's unforgettable explanation, you'll learn to love the MERGE operator, and plan your indexes so as to allow the Query Optimiser to use it.
… Read more
SQL Server Statistics assist the query optimiser to calculate the best way of running the query. Holger describes every common way that things can go wrong with statistics, and how to put matters right.
… Read more
Fabiano continues his mission to explain the Query Optimiser in practical terms, describing, one week at a time, all the major Showplan Operators used by SQL Server's Query Optimiser to build the Query Plan. He discusses the Stream Aggregate function and shows how easy it is to get performance gains in GROUP BY clauses by choosing the right index.… Read more
For the fifth part of Fabiano's mission to describe the major Showplan Operators used by SQL Server's Query Optimiser, he introduces the spool operators and particularly the Eager Spool, explains blocking and non-blocking and then describes how the Halloween Problem is avoided.… Read more
Fabiano continues in his mission to describe the major Showplan Operators used by SQL Server's Query Optimiser. This week he meets a star, the Key Lookup, a stalwart performer, but most famous for its role in ill-performing queries where an index does not 'cover' the data required to execute the query. If you understand why, and in what circumstances, key lookups are slow, it helps greatly with optimising query performance. … Read more
The third part of Fabiano's mission to describe the major Showplan Operators used by SQL Server's Query Optimiser continues with the 'Compute Scalar' operator. Fabiano shows how a tweak to SQL to avoid a 'Compute Scalar' step can improve its performance.… Read more
Fabiano continues in his mission to describe, one week at a time, all the major Showplan Operators used by SQL Server's Query Optimiser to build the Query Plan. This week he gets the Concatenation operator .… Read more
As part of his mission to explain the Query Optimiser in practical terms, Fabiano attempts the feat of describing, one week at a time, all the major Showplan Operators used by SQL Server's Query Optimiser to build the Query Plan. He starts with Assert… Read more
Fabiano launches into a sound technical explanation of the way that the query optimiser works in SQL Server with a mention of Brazilian Soccer stars and young ladies on Copacabana beach. You'll never quite think of statistics, execution plans, and the query optimiser the same way again after reading this, but we think you'll understand them better.… Read more
The Query Optimizer gets it right most of the time, but occasionally it chooses a plan that isn't the best possible. You can give the Query Optimiser a better idea by using Table, Join and Query hints. These come with a risk: Any choices you force on the Optimizer by using hints can turn out to be entirely wrong as the database changes with the addition of data over time. Grant Fritchey, in a chapter from his highly acclaimed book, explains further.
… Read more
