Learning SQL for data analysis: the queries you will use every week

By Axyra Nova Editorial · 9 October 2026 · 5 min read · Data and AI

SQL, short for Structured Query Language, is the standard way to ask questions of data stored in relational databases. Almost every organisation that keeps records, from online shops to hospitals, stores much of its data in databases that speak SQL. For analysts, it is one of the most valuable skills to have, and the basics can be learned in a few weeks.

This guide explains how to learn SQL for data analysis, focusing on the queries you will use most often.

Why analysts need SQL

Spreadsheets are excellent for small datasets, but they struggle with millions of rows or data spread across many tables. SQL lets you:

  • Pull exactly the data you need from large databases.
  • Combine information from several tables.
  • Summarise data by group, such as sales by month or region.
  • Repeat the same analysis reliably whenever the data updates.

Many analyst roles list SQL as a core requirement, alongside spreadsheets and a visualisation tool.

Setting up somewhere to practise

You need a database to practise on. Options include:

  • Online interactive courses with built-in databases, such as Kaggle's SQL course and Mode's SQL tutorial.
  • A local database such as PostgreSQL, installed on your own computer. The PostgreSQL tutorial walks through installation and first queries.
  • Lightweight databases like SQLite, which store a whole database in a single file.

Starting with an online course avoids setup problems while you learn the basics. Kaggle Learn offers short, free SQL lessons that run in the browser against real public datasets.

The building blocks

The examples below use a simple table called orders with columns for order ID, customer ID, order date, region and amount.

SELECT and FROM

Choose which columns to return and from which table:

SELECT order_id, order_date, amount
FROM orders;

WHERE

Filter rows that meet a condition:

SELECT order_id, amount
FROM orders
WHERE region = 'Lagos' AND amount > 10000;

ORDER BY and LIMIT

Sort the results and limit how many rows you see:

SELECT order_id, amount
FROM orders
ORDER BY amount DESC
LIMIT 10;

Aggregate functions

Summarise many rows into one value with COUNT, SUM, AVG, MIN and MAX:

SELECT COUNT(*) AS order_count, SUM(amount) AS revenue
FROM orders;

GROUP BY

Summarise by category:

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

HAVING

Filter groups after aggregation:

SELECT customer_id, COUNT(*) AS orders
FROM orders
GROUP BY customer_id
HAVING COUNT(*) >= 3;

Joining tables

Real databases split data into related tables. A customers table might hold names and sign-up dates, while orders holds purchases. A join combines them:

SELECT c.name, o.order_date, o.amount
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.order_date >= '2026-01-01';

The main types of join are:

  • INNER JOIN: only rows with a match in both tables.
  • LEFT JOIN: all rows from the first table, with matching rows from the second where they exist.
  • RIGHT and FULL joins: less common, but useful in specific cases.

Understanding joins is the biggest step from beginner to confident SQL user. Practise them until you can predict exactly which rows a query will return.

Handling missing values

Missing data is stored as NULL, which behaves differently from zero or an empty string. Key points:

  • Use IS NULL and IS NOT NULL to test for missing values.
  • Aggregate functions like SUM and AVG ignore NULLs.
  • COALESCE replaces NULL with a default value.
SELECT customer_id, COALESCE(phone, 'not provided') AS phone
FROM customers;

Working with dates

Analysts constantly group data by day, week or month. Date functions vary between databases, so check the documentation for yours. In PostgreSQL, for example, you might group by month like this:

SELECT date_trunc('month', order_date) AS month, SUM(amount) AS revenue
FROM orders
GROUP BY month
ORDER BY month;

Writing readable queries

Queries are read more often than they are written. Make them easy to follow:

  • Put each clause on its own line.
  • Use clear aliases for tables and columns.
  • Add comments for anything non-obvious.
  • Break complex logic into steps with common table expressions, written with WITH.

Common beginner mistakes

Most SQL errors fall into a few familiar patterns:

  • Forgetting GROUP BY columns. Every column in the SELECT list that is not inside an aggregate function usually needs to appear in GROUP BY.
  • Filtering aggregates with WHERE. WHERE filters rows before grouping; HAVING filters groups afterwards.
  • Comparing with NULL using equals. A condition like "phone = NULL" never matches; use IS NULL instead.
  • Accidental duplicates from joins. If a customer has three orders, joining customers to orders produces three rows for that customer. Check row counts after every join.
  • Trusting results without checking. Pick one or two records you understand and confirm the query returns what you expect for them.

Building the habit of checking a small sample by hand will catch most of these before anyone else sees your results.

A learning plan

WeekFocus
1SELECT, WHERE, ORDER BY, LIMIT
2Aggregates, GROUP BY, HAVING
3Joins and handling NULLs
4Dates, CASE expressions, subqueries and WITH
5–6A project with a real public dataset

A worked example

An operations assistant at a small online shop wanted to know which products were most often bought together and which regions had the most returns. The data lived in the shop's database, but she had only ever used exported spreadsheets.

After a few weeks of evening practice, she wrote queries joining the orders, order items and returns tables, grouping by region and product. Her first results looked wrong because some orders had no matching returns; switching to a LEFT JOIN fixed it. She saved her queries so she could rerun them each month instead of rebuilding spreadsheets.

Her analysis showed that most returns came from a single product with a misleading size description, which the shop then rewrote.

Practising with real data

Public datasets give you realistic practice. After the basics, choose a dataset that interests you, ask five questions about it and answer each with SQL. Write up what you found. This makes a strong portfolio project; our guide to a tech portfolio that gets interviews explains how to present it.

Next steps

Once you are comfortable with SQL, combine it with a visualisation tool or Python. Our guides to a first Power BI dashboard and pandas for beginners cover those next steps. The data track on our learning platform lists free courses in order.

Frequently asked questions

How long does it take to learn SQL?

The basics can be learned in a few weeks of regular practice. Confidence with joins and complex queries takes longer and comes with real projects.

Which database should I learn?

The core of SQL is similar across databases. PostgreSQL is a good, free choice, and the skills transfer to others.

Do I need to know programming first?

No. SQL is often the first technical language analysts learn.

Is SQL still relevant with AI tools?

Yes. AI tools can help write queries, but you still need to understand SQL to check that results are correct.