ContentsThe library

Why a Query Is Slow

A Method Instead of a Guess

Last timeWhat Every Index Costs

A slow query is fixed by a short ordered procedure, not by adding indexes until something improves. Two numbers from the plan decide almost everything that follows.

Everything so far has been description. This lesson is the procedure: what to do,

in what order, when a query is slow and somebody is waiting.

The order matters more than any individual technique. The common failure is not

ignorance about indexes but changing something plausible, seeing no improvement,

changing something else, and repeating, until the table carries half a dozen

speculative indexes, the writes are slower, and the query is still slow.

FIG 1The procedure, in the order the steps belong in
Every path begins and ends at the same box. The branches in the middle only choose which of five moves to make, which is a smaller decision than it feels like when the pressure is on.

Start with what the database already knows

Ask the system what it did. Every major database will report the plan it chose,

the rows each step actually produced, and the time each step consumed. That one

output answers the three questions the diagnosis needs: where the time

went, how many rows were really touched, and whether the estimates were close.

Reading it takes a minute and replaces an hour of speculation.

Two numbers in it decide almost everything that follows.

The first is rows examined against rows returned. A step reading nine million

rows to produce forty is doing something far more expensive than it needs to, and

the remedy is in the access path, meaning an index or a condition rewritten so

one can be used.

The second is estimated rows against actual rows. A step the planner expected to

produce two hundred rows that actually produced ninety thousand chose well for a

query it was told it was running, and was told wrong. No index will fix that, but

the statistics will.

FIG 2The five available changes, judged on four things
effort, one to fourpossible gain, one to foongoing cost, one to fouhow often it applies, on
ask for fewer rows1414
rewrite the condition2413
add or widen an index2334
fix the statistics1312
change the data shape4442
The marked row is most often skipped and most often correct, because it costs nothing to keep and can turn an impossible access path into a trivial one. The bottom row is last because changing the data shape is the only move others have to be told about.

Five moves, and that is the whole list

The order in the table is close to the order to try them in. Asking for fewer

rows is free and often available, since a query returning fifty thousand rows to

a page showing twenty is not a database problem. Changing the data shape is last

because it is the only move that changes what other code can assume.

The lesson stops here

4 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the planThe contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

The rest of this course

  1. 01What a Query Is Actually Spending
  2. 02What an Index Actually Isopening only
  3. 03The Conditions No Index Can Rescueopening only
  4. 04Every Plan Rests on an Estimateopening only
  5. 05The Three Ways to Joinopening only
  6. 06How to Read a Planopening only
  7. 07The Bill for Every Indexopening only
  8. 08A Method Instead of a Guessyou are here

Read alongside