A query can be correct and still do too much work.
SQL Queries for Performance teaches you how to find that unnecessary work, understand why it is happening, and reduce it without changing the correct result.
Instead of starting with tuning tricks or rules to memorize, this practical guide builds a repeatable performance-investigation process. You will learn how to define what "slow" actually means, establish a trustworthy baseline, inspect the evidence a database provides, form a specific hypothesis, make a deliberate change, and measure again.
Along the way, you will learn how to:
• read execution plans without treating them like mysterious diagrams
• understand scans, access paths, row estimates, sorts, and intermediate work
• recognize queries that read, move, calculate, or return more data than necessary
• understand how predicates, joins, aggregation, subqueries, and pagination affect workload
• evaluate indexes from the query's point of view
• reason about selectivity, statistics, and changing data distribution
• distinguish a query problem from an indexing, modeling, or environment problem
• prove that a performance change actually helped while preserving correctness
The examples use Juniper Bay Market, a realistic relational database that has grown large enough for performance decisions to matter. SQLite provides a reproducible practice environment, while the core reasoning is designed to transfer to other relational database systems.
You do not need to be a database performance specialist to begin. If you are comfortable reading and writing basic SQL-including filters, joins, grouping, and aggregates-you have enough foundation.
The goal is not to memorize which SQL features are supposedly "fast" or "slow."
The goal is to be able to look at a performance problem and ask:
What work did the database perform, why did it perform that work, and what evidence shows that our change made things better?
