SQL for Data Analysts: A Practical Start

A data analyst spends most of the day answering questions like "How much did we sell last month?", "Which customers stopped ordering?" and "Which region grew fastest this quarter?" Nearly every one of those answers starts as a SQL query against tables someone else already built. You are not designing the database or inserting data — you are reading it and shaping it into a report a manager can act on. That reading-and-summarizing subset of SQL is what this guide covers, and it is smaller than most people expect.

This page is the map for the whole SQL for analytics learning path. It shows which query patterns matter, why each one exists, and where each links to a deeper tutorial. Treat it as the overview; follow the links to practice each skill in depth.

What "analyst SQL" actually is

Developers use SQL to build and maintain applications: create tables, insert and update rows, enforce constraints, tune performance. Analysts use a different slice. You almost always start with SELECT, point at tables that already contain orders, customers and products, and transform them into a summary. The verbs you use daily are: filter, sort, count, sum, average, join and rank. That is the job.

Here is a tiny sales table we will reuse across this cluster so the examples stay concrete:

-- 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
1006     | Chitra   | West    | Headset   | 2100   | 2026-03-22

A manager asks: "What was total revenue by region?" As an analyst you translate that sentence into SQL:

SELECT region,
       SUM(amount) AS total_revenue,
       COUNT(*)    AS order_count
FROM orders
GROUP BY region
ORDER BY total_revenue DESC;

region | total_revenue | order_count
-------+---------------+------------
South  | 10300         | 3
North   | 8500         | 1
West   | 3300          | 2

That single query — filter nothing, group by a dimension, sum a measure, sort the result — is the shape of a huge portion of analytics work. Everything else is a variation or a refinement of it.

The core toolkit, in order

The path through this cluster follows how questions get harder in real work.

Selecting and filtering. Every report begins by choosing columns and narrowing rows: "only this quarter", "only the South region", "only orders above 5000". This is SELECT and WHERE for analysts, the foundation everything else sits on.

Sorting and limiting. "Top 10 customers", "most recent orders", "lowest-margin products" all need ORDER BY and LIMIT to rank and trim results.

Summarizing. Turning many rows into one number — total revenue, average order value, customer count — is the heart of reporting. Learn the five aggregate functions, then combine them with GROUP BY and HAVING to summarize per region, per month or per product.

Combining tables. Real businesses split data across tables: orders in one, customer details in another, products in a third. JOINs stitch them back together so you can report on customer names, not just IDs. Self joins handle a table referencing itself, like employees and their managers.

Layering logic. When one question depends on the answer to another — "customers who spent above the average" — you reach for subqueries and, for readability, common table expressions (CTEs).

Ranking and running totals. Dashboards constantly need "rank within region", "running monthly total" or "this row versus the group average". Those need window functions, the skill that most separates a junior from a strong analyst.

Conditional buckets. Turning raw values into labels — "High/Medium/Low value", "New vs Returning" — uses the CASE statement, the analyst's if-then tool.

How analysts actually use it

In practice you rarely write a query from scratch and get it right in one shot. You build it up. Start with a plain SELECT * FROM orders LIMIT 20 to see the data. Add a WHERE to narrow it. Add GROUP BY and an aggregate to summarize. Add a JOIN to bring in names. Layer ORDER BY to rank. Each step you re-run and sanity-check the numbers against something you already know. A report that "looks right" but has a silent join duplication is worse than no report, so this incremental habit is the real professional skill.

Common mistakes

• Trusting a number you did not sanity-check. A join that fans out rows can double your revenue total. Always verify a headline figure against a known reference before shipping it.
• Filtering after aggregating with WHERE. You cannot filter a SUM with WHERE; that is what HAVING is for. Confusing the two is the most common beginner error.
• Forgetting NULLs. COUNT(column) skips NULLs, AVG ignores them, and a WHERE amount > 1000 silently drops rows where amount is NULL. Missing data changes answers.
• Selecting a column that is neither grouped nor aggregated. After GROUP BY, every selected column must be a grouping key or wrapped in an aggregate, or the query fails.

In interviews

Data analyst interviews lean heavily on SQL. Expect a schema of two or three tables (orders, customers, products) and questions like "total revenue per region", "top 3 customers by spend", "month-over-month growth" or "customers who ordered in January but not February". These test joins, grouping, subqueries and window functions — exactly the cluster above. Interviewers care less about perfect syntax and more about whether you can decompose a vague business question into clear steps and reason about edge cases like NULLs and duplicates.

Where this fits in your learning path

This overview anchors the data analytics learning path. Start with SELECT and WHERE to build the filtering foundation, then move to aggregate functions to start summarizing. If you are aiming for a role, the structured data analyst roadmap sequences SQL alongside the other skills employers expect.