SQL is the single most requested skill in analyst job ads — it's how you get data out of databases to analyse. This guide covers the analyst's core SQL, and builds on the full Databases & SQL Fundamentals library.
Reuse: For deeper coverage of relational design, keys, transactions, indexes and NoSQL, work through the existing SQL Fundamentals guide and its topics (e.g. JOINs, CRUD, keys & relationships). This guide focuses on using SQL for analysis.
SELECT — getting data
SELECT product, region, sales
FROM orders
WHERE region = 'North' AND sales > 100
ORDER BY sales DESC
LIMIT 10;
SELECT chooses columns, FROM the table, WHERE filters rows, ORDER BY sorts, LIMIT caps rows. This is 80% of day-to-day analyst SQL.
Aggregations with GROUP BY
The analyst's workhorse — summarise data by group:
SELECT region, SUM(sales) AS total_sales, COUNT(*) AS orders
FROM orders
GROUP BY region
HAVING SUM(sales) > 10000
ORDER BY total_sales DESC;
Aggregate functions: SUM, COUNT, AVG, MIN, MAX. GROUP BY collapses rows into groups; HAVING filters groups (unlike WHERE, which filters rows before grouping).
JOINs — combining tables
Data lives in multiple related tables, so you join them on a shared key:
- INNER JOIN — only matching rows in both tables.
- LEFT JOIN — all rows from the left table, plus matches (nulls where none) — great for "customers with no orders".
SELECT c.name, SUM(o.sales) AS total
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.name;
Order of execution (why queries behave oddly)
SQL runs in this logical order: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. That's why you can't use a SELECT alias in WHERE, but can in ORDER BY — a favourite interview gotcha.
Put it to work
Practise live in the interactive SQL Fundamentals lab (runs in your browser), then apply it in the Sales Analysis scenario.