SQL Skills Every Aspiring Data Analyst Should Learn
Practise filters, aggregation, joins and window calculations without losing data meaning.
Part of the Data Analytics track: modules, projects and first roles →
By the GullyMentor team · 5 min read · Published 2026-10-18 · Updated 2026-11-06 · Sources listed at the end. Not a promise about mentorship outcomes.
An aspiring data analyst needs SQL to retrieve and summarise structured data. The core skill is writing a query whose result matches the business question and whose row behaviour you can explain. Learn selection, filtering, grouping, joins and window calculations, and check each result by hand.
Which SQL skills matter first?
In order: selecting and filtering, aggregating at the right level, joins, then conditional and window calculations. Each skill below has a small check. The wider path is in the data analytics track and the data analyst roadmap.
How do you select and filter correctly?
Use a fictional orders table with order_id, customer_id, order_date, amount and status. Select only the fields you need. Decide which statuses count as completed sales and write that rule down.
Check date boundaries carefully. An inclusive start and an exclusive start of the next period are easier to reason about than guessing the last second of a month:
``
WHERE order_date >= '2026-10-01'
AND order_date < '2026-11-01'
AND status = 'completed'
``
How do you aggregate at the right level?
Group by the dimension that answers your question, such as month or region. Know the difference between row count, unique-order count and customer count.
If three order lines belong to one order, COUNT(*) returns three rows. That may be right for item lines and wrong for an order-volume report. Write the intended grain as a comment above the query, for example "one row per order".
How do joins go wrong?
Join orders to customers using the right key. An inner join drops unmatched orders. A left join keeps them. Neither is universally correct.
Try this exercise. Create two customers and three orders, including one order with a customer ID that matches nobody. Work out the expected result on paper, then run the join. Now add two customer rows with the same ID and watch the totals multiply. This is a common source of inflated reports.
| Situation | What you see | Likely cause |
|---|---|---|
| Revenue far higher than expected | Totals are doubled | Duplicate keys on the joined table |
| Orders missing from a report | Row count drops | Inner join on an unmatched key |
What are conditional and window calculations?
Conditional aggregation separates completed and refunded amounts in one query. Window functions rank products or compare a row with an earlier period while keeping row detail.
Before calculating growth, decide what happens when the prior value is zero or missing. An undefined rate should not become a misleading zero.
What are the common mistakes?
- Using COUNT(*) when you meant distinct orders.
- Filtering a left-joined table in WHERE, which quietly turns it into an inner join.
- Forgetting that NULL is not equal to anything, including another NULL.
- Trusting a result because the query ran without errors.
- Copying date syntax from another database.
How do you check your query is right?
Take a tiny table of five or six rows and compute the answer by hand. Run the query and compare. Then change the data on purpose: add a duplicate key, a NULL amount and an unmatched ID. Your query should behave in a way you can predict and explain. If you cannot explain a number, you do not yet trust it.
What should you practise?
Build one query each for monthly sales, customers without orders and top products within each region. Save the input tables and the expected outputs next to the queries. Check nulls, duplicates and unmatched keys every time.
Use a local learning database with synthetic data and read-only access where possible. Exact date and function syntax differs by database, so consult its current documentation. The PostgreSQL tutorial is a good free reference.
Present your reasoning and validation alongside the final result. Interviewers and teammates trust a query more when you show how you checked it.
Worked example: monthly completed sales
The question is "how much did we sell each month?" The grain is one row per order, so use distinct orders if lines are repeated. Filter to completed status, group by month, sum the amount and count distinct order_id. Then take three orders from one month and add them by hand. If your query shows a different total, look for refunded rows, duplicate keys or a date boundary problem before you trust it.
What should you build next?
Use these queries in a business dashboard and in the portfolio projects for freshers. Both reward careful definitions, which is exactly what this guide practised.
Sources & further reading
Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.