Reading a SELECT Statement

The one idea: You don't need to write a query — you need to look at one and answer "what is this actually asking for?" Read it in the order the database runs it (which table, then which rows, then what's returned), and never trust a column's name until you've checked what it really computes.

⚠️ The trap: It's called total_spent, so that's what customers spent — the column's name tells me what the number means. That feels right and it's wrong. An alias is just a nickname the query's author typed, and it can lie; read the calculation next to it — AS active_users on a count of sessions is still counting sessions.

Every SQL query you'll ever be shown — in a dashboard, a Slack thread, or an AI's explanation of "how I calculated this" — starts as a SELECT statement. You don't need to write one from scratch. You need to be able to look at one and answer a single question: what is this actually asking for?

The Anatomy

SELECT customer_id, SUM(order_total) AS total_spent
FROM orders
WHERE order_date >= '2026-01-01'

Read it in this order, not top to bottom:

1. FROM — which table is the data coming from? (orders)
2. WHERE — which rows are kept before anything else happens? (only orders from 2026 onward)
3. SELECT — of the rows that survived, which columns (or calculations) do we actually return? (customer_id, and a summed total)

This order — FROM, then WHERE, then SELECT — is how the database actually processes the query, even though SELECT is written first. Reading it in processing order, not reading order, is the single…