SQL Tutorial for Beginners: Learn SQL Step by Step

What SQL is, and what most tutorials skip

A relational database keeps data in tables. Each table is a grid: rows are the things (one customer, one order), columns are their facts (name, city, price). Tables point at each other through keys: an order row carries the id of exactly one customer row. SQL (Structured Query Language) is how you ask the database for rows, and how you add, change and remove them.

The one idea that makes SQL click is this: you describe the result you want, and the database works out how to get it. You never write a loop. "All paid orders, newest first, top ten" is one statement, and the database decides which index to use and in what order to read the rows. People who come from Python or JavaScript keep trying to loop; people who have never coded often find SQL easier for exactly that reason.

The core of SQL is a standard shared by all of them. Learn the core first on whichever is easiest to install; switching dialects later takes an afternoon, not a course.

Set up the practice database in ten minutes

Install SQLite (or open any SQL playground), create a new database, and run the statements below. They make three tables and fill them with a small bookshop: six customers in six countries, six books, and a handful of orders. Keep this database; the rest of the tutorial asks it questions.

CREATE TABLE customers (
  id      INTEGER PRIMARY KEY,
  name    TEXT NOT NULL,
  country TEXT NOT NULL,
  joined  DATE NOT NULL
);

CREATE TABLE books (
  id     INTEGER PRIMARY KEY,
  title  TEXT NOT NULL,
  author TEXT,
  price  NUMERIC NOT NULL
);

CREATE TABLE orders (
  id          INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers(id),
  book_id     INTEGER NOT NULL REFERENCES books(id),
  quantity    INTEGER NOT NULL,
  status      TEXT,
  placed_at   DATE NOT NULL
);

INSERT INTO customers VALUES
  (1, 'Amina',  'Kenya',       '2026-01-05'),
  (2, 'Rafael', 'Brazil',      '2026-01-20'),
  (3, 'Priya',  'India',       '2026-02-02'),
  (4, 'Tomas',  'Poland',      '2026-02-14'),
  (5, 'Hana',   'Japan',       '2026-03-01'),
  (6, 'Grace',  'Australia',   '2026-03-09');

INSERT INTO books VALUES
  (1, 'Learning SQL',          'Alan Beaulieu',   30.00),
  (2, 'Python Crash Course',   'Eric Matthes',    35.00),
  (3, 'Clean Code',            'Robert C. Martin', 40.00),
  (4, 'The Pragmatic Programmer', NULL,           45.00),
  (5, 'Think Stats',           'Allen Downey',    25.00),
  (6, 'Eloquent JavaScript',   'Marijn Haverbeke', 20.00);

INSERT INTO orders VALUES
  (1, 1, 1, 1, 'paid',    '2026-03-01'),
  (2, 2, 2, 2, 'paid',    '2026-03-02'),
  (3, 1, 3, 1, 'paid',    '2026-03-05'),
  (4, 3, 1, 1, 'pending', '2026-03-06'),
  (5, 4, 5, 3, 'paid',    '2026-03-08'),
  (6, 2, 6, 1, 'cancelled', '2026-03-09'),
  (7, 5, 2, 1, 'paid',    '2026-03-10'),
  (8, 1, 5, 2, NULL,      '2026-03-12');

Three things to notice before you query it. PRIMARY KEY means every row has a unique id. REFERENCES means an order must point at a customer and a book that exist. And two cells are NULL: one book has no author recorded and one order has no status. NULL means "unknown", and it will catch you in lesson 2.

Lesson 1: SELECT, FROM, WHERE, ORDER BY, LIMIT

A query names the columns you want, the table they come from, and the condition the rows must meet. Read it in the order the database runs it: FROM (which table), WHERE (which rows), SELECT (which columns), then ORDER BY and LIMIT.

SELECT id, quantity, placed_at
FROM orders
WHERE status = 'paid'
ORDER BY placed_at DESC
LIMIT 3;

Before you run it, say how many rows you expect. There are five paid orders; the three newest are orders 7, 5 and 3. Run it. If you got something else, you have found your first bug, and finding it on eight rows is the whole point of a small database.

• SELECT * returns every column. Fine while exploring; name the columns in anything you keep.
• WHERE takes =, <> (not equal), <, >, BETWEEN, IN ('paid', 'pending'), and LIKE 'A%' for text patterns. Combine with AND, OR and brackets; mixed AND/OR without brackets is the first classic mistake.
• ORDER BY sorts; add DESC for newest or largest first. Without it, row order is an accident the database may change tomorrow.
• LIMIT caps the rows. With ORDER BY it answers every "top ten" question.
• DISTINCT removes duplicate rows from the result: SELECT DISTINCT country FROM customers;

Try: every customer who joined after 1 February 2026, alphabetically. Every order of two or more copies. The cheapest book. Predict the rows, then run.

Lesson 2: NULL, expressions and CASE

NULL is not zero and not an empty string. It means the fact is unknown, and anything compared with unknown is unknown. So WHERE status = NULL returns nothing, silently, not even an error. The test is IS NULL.

SELECT id FROM orders WHERE status = NULL;        -- returns nothing, always
SELECT id FROM orders WHERE status IS NULL;       -- order 8
SELECT id FROM orders WHERE status <> 'paid';     -- orders 4 and 6 only: the NULL row is excluded too

When rows go missing from a report, the cause is a NULL about eight times in ten. COALESCE(status, 'unknown') replaces a NULL with a value you choose, which is how reports show "unknown" instead of a blank.

Columns can be combined into expressions, and CASE is SQL's if-then-else, inside the SELECT:

SELECT title,
       price,
       price * 0.9 AS sale_price,
       CASE WHEN price >= 40 THEN 'premium'
            WHEN price >= 30 THEN 'standard'
            ELSE 'budget' END AS tier
FROM books
ORDER BY price DESC;

AS gives a column a name for this query. Common functions you will use every week: LOWER, UPPER, LENGTH and TRIM for text; ROUND for numbers; and your dialect's date functions (strftime in SQLite, date_trunc in PostgreSQL) for grouping by month.

Lesson 3: GROUP BY, aggregates and HAVING

Aggregates collapse many rows into one answer: COUNT, SUM, AVG, MIN, MAX. On their own they summarise the whole table. With GROUP BY they summarise each group: per customer, per country, per month.

SELECT customer_id,
       COUNT(*)      AS orders,
       SUM(quantity) AS books_bought
FROM orders
WHERE status = 'paid'
GROUP BY customer_id
ORDER BY books_bought DESC;

The rule that explains almost every GROUP BY error: every column in the SELECT is either in the GROUP BY or inside an aggregate. If you ask for placed_at while grouping by customer, there are several dates per customer and no single one to print, so the database refuses (or, in older MySQL, guesses, which is worse).

• COUNT(*) counts rows. COUNT(status) counts rows where status is not NULL. On our orders table they give 8 and 7. Two questions, one verb.
• Aggregates ignore NULL, so AVG over a sparse column averages only the known values. Decide whether that is what you meant.
• WHERE filters rows before grouping. HAVING filters groups after: HAVING SUM(quantity) >= 3 keeps only customers who bought three or more books. WHERE cannot see the sum, because it runs first.

Try: how many customers per country. The average book price. Countries with more than one customer (none yet; add a customer and watch it appear).

Lesson 4: JOIN, the lesson that makes SQL useful

Real questions cross tables. "Which customers bought which books" needs orders, customers and books together, and a join does that by matching keys: orders.customer_id to customers.id.

SELECT c.name, c.country, b.title, o.quantity, o.placed_at
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
JOIN books     AS b ON b.id = o.book_id
WHERE o.status = 'paid'
ORDER BY o.placed_at;

The ON clause says how rows pair up. It is almost always a key equality, and getting it wrong does not produce an error: it produces too many rows, each one looking plausible. This is why you predict the row count first. Five paid orders in, five rows out. If you see twenty-five, a join has fanned out.

The LEFT JOIN version of "customers and their order counts" is the one most beginners get wrong, so here it is in full. Grace, who has never ordered, must appear with zero, and that needs COUNT(o.id), not COUNT(*), because the unmatched rows carry a NULL order id:

SELECT c.name, COUNT(o.id) AS orders
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY orders DESC, c.name;

Try: total money taken per book (price times quantity, paid orders only). Which books have never been ordered (a LEFT JOIN where the order side IS NULL).

Lesson 5: subqueries, a question inside a question

Sometimes the answer to one question is the input to another. "Books that cost more than the average" needs the average first. A subquery in brackets returns a value or a list that the outer query uses.

-- books above the average price
SELECT title, price
FROM books
WHERE price > (SELECT AVG(price) FROM books);

-- customers who have at least one paid order
SELECT name
FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE status = 'paid');

-- the same, the way experienced people write it
SELECT name
FROM customers AS c
WHERE EXISTS (SELECT 1 FROM orders AS o
              WHERE o.customer_id = c.id AND o.status = 'paid');

IN compares against the subquery's list. EXISTS asks only "is there at least one row", which is usually what you mean and usually faster. Neither multiplies rows, which makes them the safe way to filter one table by another when a join would fan out.

When a query gets long, name the pieces with a WITH clause (a common table expression, or CTE). It reads top to bottom like a short program:

WITH paid AS (
  SELECT customer_id, SUM(quantity) AS books_bought
  FROM orders
  WHERE status = 'paid'
  GROUP BY customer_id
)
SELECT c.name, c.country, paid.books_bought
FROM paid
JOIN customers AS c ON c.id = paid.customer_id
WHERE paid.books_bought >= 2;

Lesson 6: INSERT, UPDATE, DELETE and designing a table

Reading is most of SQL, but you also add, change and remove rows. The two rules: always write the WHERE before the rest of an UPDATE or DELETE, and run it as a SELECT first to see exactly which rows it will touch.

INSERT INTO orders (id, customer_id, book_id, quantity, status, placed_at)
VALUES (9, 6, 4, 1, 'paid', '2026-03-15');

SELECT * FROM orders WHERE id = 8;            -- look first
UPDATE orders SET status = 'paid' WHERE id = 8; -- then change exactly that row

DELETE FROM orders WHERE status = 'cancelled';  -- without WHERE, this empties the table

Designing a table is deciding what the database will refuse. Every NOT NULL, PRIMARY KEY, REFERENCES and UNIQUE is a promise about every row, and the database keeps it for you forever, which is far cheaper than cleaning bad data later.

• One fact per column, one thing per row. A column holding "red, blue, green" is three facts; make a second table.
• Every table has a primary key. Usually an integer id the database generates.
• Point at other tables with their id, never by copying their name. If the customer renames, one row changes.
• Store money as an exact decimal type (NUMERIC), never floating point; and store dates as dates, not text, so they sort and subtract correctly.
• Use a transaction for changes that belong together: BEGIN; the statements, then COMMIT; (or ROLLBACK; if something fails). Moving stock from one shelf to another is one change, not two.

A worked example: ten questions for the bookshop

Here are the questions a bookshop owner would actually ask, in rising difficulty, each with the query. Cover the right-hand column, write your own, then compare. Different wording that returns the same rows is a pass.

The last one is the kind of question that separates knowing the keywords from knowing SQL: it needs EXISTS, NOT EXISTS and the NULL rule together. If you can write it without looking, you have finished the beginner stage.

A two-week plan, thirty minutes a day

After the two weeks, keep one query a day from memory for another two weeks (the spaced reviews in How to memorize faster apply to code exactly as to facts). Then learn the parts this tutorial leaves out, in this order: indexes and reading a query plan, window functions (ROW_NUMBER, running totals), and the date functions of your dialect.

The mistakes that keep beginners stuck

• Watching tutorials instead of typing. SQL looks obvious on a screen and falls apart at a blank prompt. Type every query, including the ones you are sure of.
• Not predicting the row count. The prediction is the test. A join that returns 25 rows instead of 5 is only a bug if you knew to expect 5.
• Treating NULL as a value. = NULL never matches. <> excludes the NULL rows. COUNT(column) skips them. Learn the three rules once.
• Selecting a column you did not group by. Either group by it or wrap it in an aggregate.
• Mixing AND and OR without brackets. AND binds tighter; write the brackets even when you do not need them.
• UPDATE or DELETE without WHERE. Run the SELECT first, every time, however small the table.
• Learning a dialect's extras before the core. Window functions and JSON columns are useful later; joins and GROUP BY are what every job needs first.
• Starting on a huge sample database. Eight rows you can count by hand teach joins faster than a million rows you cannot check.

Frequently asked questions