SELECT and WHERE for Data Analysts

Every report an analyst builds begins with two decisions: which columns to show, and which rows to keep. SELECT answers the first, WHERE answers the second. Get comfortable with these two clauses and you can already answer a surprising share of the business questions that land on your desk — "show me South-region orders above 5000 from the first quarter" is nothing more than a well-chosen SELECT and a precise WHERE.

This tutorial frames both clauses around real reporting work rather than abstract syntax. It sits early in the SQL for analytics path, because filtering is the foundation that grouping, joining and ranking all build on.

Choosing columns with SELECT

SELECT lists the columns your report displays. Here is the sample orders table used across this cluster:

-- orders
order_id | customer | region | product  | amount | order_date
---------+----------+--------+----------+--------+-----------
1001     | Aarti    | South  | Keyboard | 1200   | 2026-01-05
1002     | Bhaskar  | South  | Monitor  | 8500   | 2026-01-11
1003     | Chitra   | West   | Keyboard | 1200   | 2026-02-02
1004     | Aarti    | South  | Mouse    | 600    | 2026-02-18
1005     | Devan    | North  | Monitor  | 8500   | 2026-03-09

To show just the customer and amount for every order:

SELECT customer, amount
FROM orders;

customer | amount
---------+-------
Aarti    | 1200
Bhaskar  | 8500
Chitra   | 1200
Aarti    | 600
Devan    | 8500

SELECT * returns every column, which is handy for exploring an unfamiliar table but poor practice in a finished report — it pulls more data than needed and makes output harder to read. Name the columns you actually want. You can also rename them for clarity with AS, which is how dashboard-ready labels are created:

SELECT customer AS customer_name,
       amount   AS order_value
FROM orders;

Narrowing rows with WHERE

WHERE keeps only the rows that meet a condition. To see only South-region orders:

SELECT customer, amount, region
FROM orders
WHERE region = 'South';

customer | amount | region
---------+--------+-------
Aarti    | 1200   | South
Bhaskar  | 8500   | South
Aarti    | 600    | South

The comparison operators are what you expect: =, <> (not equal), >, <, >=, <=. Text values go in single quotes; numbers do not. This one clause is how you scope any report to "just this segment".

Combining conditions

Business questions usually stack conditions. AND requires all to be true; OR requires any. To find South-region orders above 1000:

SELECT customer, amount
FROM orders
WHERE region = 'South' AND amount > 1000;

Mixing AND and OR requires parentheses, or you will get wrong answers. "South or West region, and above 1000" must be written:

SELECT customer, region, amount
FROM orders
WHERE (region = 'South' OR region = 'West')
  AND amount > 1000;

Without the parentheses, AND binds tighter than OR, and the query would return all South orders plus only West orders above 1000 — a classic reporting bug that quietly inflates or deflates the numbers.

The operators analysts lean on

A handful of operators cover most filtering needs:

• BETWEEN for ranges, especially dates: WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31' gives Q1. It is inclusive of both ends.
• IN for a set of allowed values: WHERE region IN ('South','West') is cleaner than chaining OR.
• LIKE for text patterns: WHERE product LIKE 'Mon%' matches anything starting with "Mon", so "Monitor" is included. % matches any run of characters, _ matches exactly one.
• IS NULL / IS NOT NULL for missing data: WHERE region IS NULL finds orders with no region recorded.

SELECT customer, product, amount, order_date
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31'
  AND product IN ('Keyboard', 'Monitor')
  AND amount > 1000;

This reads almost like the English request that produced it: January orders for keyboards or monitors worth more than 1000.

Practical usage: from question to filter

The analyst skill is translation. A stakeholder says "pull the high-value new-customer orders from last month". You decompose that: "last month" becomes a date BETWEEN, "high-value" becomes amount > some threshold, and "new-customer" becomes a condition you may need a join or subquery for later. You start with the WHERE conditions you can express now, run it, eyeball the rows, and refine. Filtering is iterative, and running the query against a small slice first keeps you from shipping a wrong number.

Common mistakes

• NULL comparisons. WHERE amount > 1000 silently excludes rows where amount is NULL, because a comparison with NULL is never true. If missing values should count, handle them explicitly with IS NULL or COALESCE.
• Operator precedence. Forgetting parentheses when mixing AND and OR produces subtly wrong result sets. Always group OR conditions in parentheses.
• Quoting numbers or forgetting to quote text. WHERE amount > '1000' may still work through implicit conversion, but WHERE region = South (no quotes) fails because SQL reads South as a column name.
• Using = NULL. This never matches anything. Missing values require IS NULL, not = NULL.

In interviews

Filtering questions appear as warm-ups: "return all orders from the West region in February above 2000". The follow-ups probe your care: "what happens to rows where amount is NULL?", "how would you find customers with no region recorded?" A strong answer names the NULL behaviour and precedence rules without being prompted. Interviewers use these to check that you filter deliberately rather than by trial and error.

Where this fits in your learning path

SELECT and WHERE are step one of the SQL for analytics path. Once you can scope data to the right rows, the natural next step is ordering and trimming results with ORDER BY and LIMIT, then summarizing them with aggregate functions. All three together form the base of every dashboard on the data analyst roadmap.