Your First 10 SQL Queries: SELECT, WHERE, ORDER BY and LIMIT

Every query in this guide runs against the same table: a 200-row orders table from a small online retailer. That's deliberate. Jumping between a different toy table for every example is how a lot of SQL tutorials make ten simple ideas feel like ten unrelated ones. Here, the table stays constant and only the query changes, which is a much closer match to how you'll actually work: the same schema, asked a lot of different questions.

The 10 SQL Query Patterns You'll Learn

These aren't ten unrelated SQL tricks. They're ten query patterns built from four core clauses: SELECT, WHERE, ORDER BY, and LIMIT.

The table, orders:

The real table has 200 rows across these same eight columns, more products, more customers, more regions. These five are enough to check your own results against as you go.

1. See everything

sql

SELECT * FROM orders;

* means "every column." This returns all 200 rows, every column, unfiltered and unsorted. It's the query you run first on any new table, purely to see what you're working with, and it's rarely the query you actually want as a final answer.

2. See only the columns you need

sql

SELECT customer_name, product, price FROM orders;

Naming specific columns instead of * is worth doing as a habit even when you're just exploring, since it forces you to think about which columns actually matter to the question you're asking, and it's what you'll do in almost every real query from here on.

3. Limit how many rows come back

sql

SELECT customer_name, product, price FROM orders LIMIT 5;

LIMIT 5 caps the result at five rows. On a 200-row table this doesn't matter much, but on a real table with millions of rows, SELECT * with no limit can be slow or genuinely expensive to run. Getting into the habit of limiting a first exploratory query is worth carrying forward. PostgreSQL's documentation on LIMIT and OFFSET covers the syntax in more depth, including why pairing LIMIT with ORDER BY matters for getting a consistent result.

4. Filter rows with a text condition

sql

SELECT * FROM orders WHERE category = 'Electronics';

WHERE filters rows before they're returned, keeping only the ones where the condition is true. Text values in the condition need single quotes around them, 'Electronics', not double quotes, which is a small syntax detail that trips up a lot of beginners moving from other languages.

5. Filter rows with a numeric condition

sql

SELECT * FROM orders WHERE price > 2000;

Numeric comparisons don't need quotes. >, <, >=, <=, and = all work the way you'd expect from basic arithmetic. This query returns every order over ₹2,000, regardless of category or customer.

6. Combine conditions with AND

sql

SELECT * FROM orders WHERE category = 'Electronics' AND price > 2000;

AND requires both conditions to be true for a row to be included. This narrows the previous two queries down to their overlap: electronics orders specifically over ₹2,000, not all electronics and not all orders over ₹2,000 separately.

7. Combine conditions with OR

sql

SELECT * FROM orders WHERE category = 'Electronics' OR category = 'Fitness';

OR requires at least one condition to be true. This is a common point of confusion for beginners: AND narrows a result down, OR usually widens it. A query asking for category = 'Electronics' AND category = 'Fitness' would return nothing at all, since no single row can belong to two categories at once, which is a genuinely useful mistake to make once so it sticks.

8. Sort a result, smallest to largest

sql

SELECT customer_name, product, price FROM orders ORDER BY price ASC;

ORDER BY sorts the result set. ASC, ascending, is actually the default, so you'll often see this written without it, but including it explicitly while you're still learning is a reasonable habit until the direction is second nature.

9. Sort a result, largest to smallest

sql

SELECT customer_name, product, price FROM orders ORDER BY price DESC;

DESC reverses the sort order. This single-word change is how most "top N" business questions get answered, biggest orders, most recent signups, highest churn, and it's worth knowing cold rather than looking up every time.

10. Put it all together

sql

SELECT customer_name, product, price
FROM orders
WHERE category = 'Electronics'
ORDER BY price DESC
LIMIT 5;

This is the query that actually looks like real work: the five highest-value electronics orders in the table. Notice the order the clauses are written in, SELECT, FROM, WHERE, ORDER BY, LIMIT, which is fixed. SQL won't run if you write ORDER BY before WHERE, even though logically you might think about sorting before filtering. PostgreSQL's SELECT documentation lays out the full clause order for anyone who wants the complete syntax reference. Writing clauses in this order is worth memorising early, since it's the shape every more advanced query in this series will build on.

Common mistakes

• Using double quotes for text values. WHERE category = "Electronics" fails or behaves unexpectedly in many SQL dialects; single quotes are the safe default for text.

• Writing clauses out of order. SELECT, FROM, WHERE, ORDER BY, LIMIT is the fixed order. A query with ORDER BY before WHERE won't run.

• Confusing AND and OR. AND narrows a result to rows meeting every condition; OR widens it to rows meeting any one of them. Asking for two mutually exclusive values joined by AND is a common way to accidentally get zero rows back.

• Forgetting that SELECT * doesn't scale. It's fine for exploring a small table; on a large one, naming only the columns you need and adding a LIMIT while exploring is the safer default.

• Assuming ORDER BY changes the underlying table. It only changes how this particular result is displayed; the table itself is untouched.

Where to go from here

This guide covers the four clauses every other SQL topic in this series builds on top of. The natural next step is SQL CASE statements, which builds business logic directly into a query on this same orders table, followed by GROUP BY and aggregate functions, which turn a filtered, sorted list of rows like the ones above into an actual summary number; that broader ground is covered in the SQL for Data Analysts guide.

If any of this felt like it assumed more background than you have, for example why a query sometimes hits a live system and sometimes hits a separate copy of the data, Databases, Data Warehouses and Data Types covers that layer, and it's worth reading either before or after this guide. Once you're comfortable writing queries like these, Power BI data modeling picks up the same table concepts and applies them to building a report.

If you'd rather practise these ten queries against a dataset of your own choosing before moving on, a few of the beginner project ideas are a good fit for exactly that kind of practice. And if you're mapping this against the wider learning sequence, the Data Analyst roadmap shows where SQL fundamentals like this fit alongside everything else.