Fixing a slow query is a repeatable procedure, not an act of inspiration: reproduce it at realistic scale, measure to find which statement actually costs the time, read its plan to find the expensive step, form one hypothesis about why, apply one change, verify with the plan and the clock, and leave a guard behind. Running the stages in order on one schema, customers, orders, order_items and products, handles every shape in this path: a dashboard total that should be a GROUP BY, an email search with a leading wildcard that no B-tree can serve, a paginated order list that should be keyset, a list page with an N+1, and an unexplained slowness that turns out to be a lock wait. The method matters more than any single trick, because it works on the query you have never seen before.
This page walks through a repeatable way to fix a slow SQL query instead of guessing. You start by asking what work the database is doing that it does not need to do, read the execution plan to find …