Your first SQL query can work before you understand it

A working example gives you something to investigate. An empty editor gives you a blinking cursor.

If you are starting SQL from zero, try this small experiment. You will predict a result, change one part of a query, and check what changed. No joins, database administration or interview puzzles yet.

Start with four accounts

Imagine a shop has this users table. This is a deliberately tiny teaching example, not customer data.

user_id	country_code
u001	US
u002	GB
u003	US
u004	CA

One row represents one account. Two accounts can have the same country code; that does not make them the same account.

Read this query aloud as “show me all columns from users”:

SELECT *
FROM users;

SELECT says which columns to show. The asterisk means all of them. FROM names the table to read. This query reads data; it does not change the table.

Before moving on, name the two column headings you expect. Then predict the number of rows. You should expect two columns and four rows.

Change one thing

Replace the asterisk with a column name:

SELECT country_code
FROM users;

Will this give you three rows or four?

There are three countries, but still four accounts. The result contains US twice, plus GB and CA. Choosing a column changes what you can see about each row. It does not automatically combine rows that look alike.

This is a useful early distinction: the number of columns and the number of rows answer different questions.

Now ask for different values

SELECT DISTINCT country_code
FROM users;

Now you get three rows: one for each country code in this example. DISTINCT removes duplicate combinations of the selected values. With a single selected column, that means duplicate country codes.

The result order is not guaranteed in any of these queries. When order matters, you request it explicitly with ORDER BY.

There is a trap worth trying before you scroll further. Predict this result:

SELECT DISTINCT user_id, country_code
FROM users;

It returns four rows again. Each pair is different because every account has a different user_id. DISTINCT applies to the whole selected combination, not just the country column beside it.

Make the example yours

Change the country for u004 from CA to US on paper. Predict the row counts for the last three queries before running anything: four, two, four.

If you can explain those numbers, you have done more than copy SQL syntax. You have connected a query to the meaning of its result. If your prediction was wrong, change only one part and inspect it again. The small table makes the reason visible.

For a runnable version of this toy table, paste this setup and one of the queries into a SQLite session:

CREATE TABLE users (
  user_id TEXT PRIMARY KEY,
  country_code TEXT
);

INSERT INTO users VALUES
  ('u001', 'US'),
  ('u002', 'GB'),
  ('u003', 'US'),
  ('u004', 'CA');

Alternatively, SQLBrief opens with a prepared database and query in the browser. It uses a larger shop dataset, so its row counts differ from this four-row example. The first step is still to inspect what one row represents and where the result headings come from. Later exercises move through filtering, grouping, joins and reports.

SQLBrief is our product. Its SQL Basics course currently has 125 tasks, is free, and works without an account or installation. English and Russian versions are available.

If you try the first lesson, tell us where you started guessing. A task number and the sentence that confused you would give us something concrete to fix.

---

This article was prepared with an AI agent for SQLBrief. The toy SQL examples were executed locally, and the course details were checked against the live product.