How to Learn SQL Fast: A 4-Week Practical Schedule That Works

Last year, I watched a junior data analyst named Mira go from writing her first SELECT * to building a multi-table sales dashboard in just 28 days. She worked a full-time retail job and practiced 35 minutes each evening—no computer science degree, no expensive boot camp. Her secret wasn't talent; it was a structured, hands-on schedule that forced her to write real queries every single day. That's exactly what this 4-week plan delivers: a practical sprint that builds muscle memory, not theory. By the end, you'll have a portfolio project—like analyzing an e-commerce dataset with joins, aggregations, and a window function—that proves you can solve real problems with SQL.

Week 1: The SQL Foundation — SELECT, WHERE, and Your First Queries

Goal: Write 20+ basic queries from memory by Friday.

Day 1 is about zero setup. Head to DB Fiddle or SQLite Online—both run in your browser, no installs. I recommend starting with SQLite because the syntax is clean and forgiving. Load the free Chinook database (a sample music store with tables for artists, albums, tracks, and invoices). This dataset has just enough complexity to keep things interesting but not overwhelming.

Your first query should be dead simple:

SELECT * FROM Artist LIMIT 10;

Then try filtering with WHERE:

SELECT Name FROM Artist WHERE Name LIKE 'A%';

Each day, layer on one new concept: ORDER BY, DISTINCT, BETWEEN, IN. By Day 3, combine them into a query that answers a real question—like “Which tracks have a duration over 5 minutes and belong to a specific genre?”

Daily checklist (print this or keep it open):

• [ ] Write 5 SELECT queries from scratch
• [ ] Use WHERE with at least 2 conditions
• [ ] Try ORDER BY on a numeric column
• [ ] Use LIMIT to preview results
• [ ] Read the error message twice before googling

Personal tip: When I first learned WHERE, I kept forgetting that text values need single quotes. Write a query that fails on purpose—then fix it. That mistake sticks.

By Sunday, you should be able to explain what SELECT COUNT(*) FROM Invoice WHERE Total > 10; does without hesitation. If not, repeat Day 5 and 6—don't rush.

Week 2: Joins, Aggregations, and Thinking in Sets

Goal: Combine 2–3 tables and summarize data with GROUP BY.

Week 2 is where most beginners hit a wall. The mental shift is huge: you stop poking at single tables and start joining them. I tell my mentees to picture INNER JOIN like a Venn diagram—only rows that match in both tables survive. LEFT JOIN keeps all rows from the left table, filling blanks with NULL.

Start with the Chinook database's Invoice and Customer tables:

SELECT c.FirstName, c.LastName, i.Total
FROM Customer c
INNER JOIN Invoice i ON c.CustomerId = i.CustomerId
WHERE i.Total > 15
ORDER BY i.Total DESC;

Run it. See the names? That's real data talking.

Common pitfalls I've seen (and made myself):

• Forgetting the ON clause — you'll get a Cartesian product (every row joined to every row). In a 1000-row table, that's a million rows. Oops.
• Mixing up INNER JOIN and LEFT JOIN. Debug this by checking for NULLs in the right table's columns.
• Putting WHERE filters on the right table after a LEFT JOIN — that turns it back into an inner join. Use AND in the ON clause instead.

Mid-week, introduce GROUP BY and HAVING. Try finding total sales per country:

SELECT c.Country, ROUND(SUM(i.Total), 2) AS TotalSales
FROM Customer c
JOIN Invoice i ON c.CustomerId = i.CustomerId
GROUP BY c.Country
HAVING TotalSales > 100
ORDER BY TotalSales DESC;

Mini-project (end of Week 2): Using the Chinook Track, Album, and Genre tables, write a query that shows the top 5 genres by number of tracks, but only for albums released after 2000. Save this query—you'll use it in your portfolio.

Incremental insight: Most tutorials teach JOINs with tiny toy examples. Real databases have messy data—duplicate names, missing values, unexpected NULLs. Always run a quick SELECT COUNT(*) after a JOIN to verify row counts match your expectations. That habit alone saved me hours of debugging during my first week on the job.

Week 3: Subqueries, CTEs, and Window Functions — Leveling Up

Goal: Write readable, efficient queries that solve multi-step problems.

By now, you can pull data from two tables and summarize it. Week 3 tackles three concepts that separate a beginner from a practical analyst: subqueries, Common Table Expressions (CTEs), and window functions.

Subqueries vs. CTEs: Both let you build intermediate results, but CTEs are far more readable. Compare these two queries that find customers who spent more than the average:

Subquery version:

SELECT FirstName, LastName
FROM Customer
WHERE CustomerId IN (
    SELECT CustomerId
    FROM Invoice
    GROUP BY CustomerId
    HAVING SUM(Total) > (SELECT AVG(Total) FROM Invoice)
);

CTE version:

WITH CustomerSpending AS (
    SELECT CustomerId, SUM(Total) AS TotalSpent
    FROM Invoice
    GROUP BY CustomerId
),
OverallAvg AS (
    SELECT AVG(Total) AS AvgSpent FROM Invoice
)
SELECT c.FirstName, c.LastName
FROM Customer c
JOIN CustomerSpending cs ON c.CustomerId = cs.CustomerId
CROSS JOIN OverallAvg oa
WHERE cs.TotalSpent > oa.AvgSpent;

The CTE version reads top-to-bottom like a story. When I mentor beginners, I insist they write CTEs for any query with more than one aggregation—it makes debugging trivial because you can run each CTE block alone.

Window functions are the secret weapon. They let you compute running totals, rankings, and moving averages without losing row-level detail. Here's a classic—rank employees by hire date:

SELECT FirstName, LastName, HireDate,
       RANK() OVER (ORDER BY HireDate) AS HireRank
FROM Employee;

Case study: A friend analyzed a decade of sales data for a small e-commerce company. She needed to show each month's running total of revenue. A window function did it in one line:

SELECT InvoiceDate,
       SUM(Total) OVER (ORDER BY InvoiceDate) AS RunningTotal
FROM Invoice;

Without OVER, she would have needed a self-join or a cursor—both slower and harder to read.

My original take: Most guides tell you to learn subqueries before CTEs. I disagree. Start with CTEs. They force you to think modularly, and when you hit a subquery in someone else's code, you can mentally refactor it into a CTE. That's a transferable skill—like learning to cook by mise en place instead of throwing everything into one pot.

End the week by rewriting your Week 2 mini-project using a CTE. Compare readability. You'll never go back.

Week 4: Real-World Project, Optimization, and Next Steps

Goal: Build a complete portfolio project and learn how to talk about SQL in interviews.

The project: Download the Northwind database (a classic sample for e-commerce). It has 13+ tables including Orders, Order Details, Products, Customers, and Suppliers. Your task is to answer five business questions:

1. Which 10 products generated the most revenue in 2024?
2. Which customers have not placed an order in the last 6 months?
3. Show monthly sales trends for each product category.
4. Rank salespeople by total revenue, including ties.
5. Find the supplier with the longest average delivery time.

Each question requires 3–4 tables joined, at least one aggregation, and some use of CTEs or window functions. Write each query, save it, and annotate it with comments explaining your logic. That annotation becomes your interview talking point.

Optimization basics: Once your queries run, learn to make them faster.

• Indexes: Columns used in WHERE and JOIN clauses benefit from indexes. In SQLite, create one with CREATE INDEX idx_customer_id ON Orders(CustomerID);. Then run EXPLAIN QUERY PLAN before and after to see the difference.
• Avoid SELECT *: Only pull the columns you need. It reduces I/O and memory.
• Filter early: Put WHERE clauses as close to the source as possible—don't filter after a JOIN if you can filter before.

Interview prep: When a hiring manager asks “Tell me about a time you used SQL,” don't say “I queried a database.” Say: “I joined four tables to find our top customers by lifetime value, used a window function to rank them, and discovered that 20% of customers drove 80% of revenue—which led the sales team to create a VIP retention program.” That's a story. Practice telling yours.

Next steps after Week 4: Keep practicing on LeetCode SQL problems (start with Easy, then Medium). Join the r/SQL subreddit and try to answer one question per day. Consider picking up a complementary tool like Python's pandas or a BI tool (Tableau, Power BI) to visualize what you query. But don't rush—mastery comes from writing thousands of queries, not from reading about them.

FAQ: Common Questions About Learning SQL Fast

Do I need to install anything to follow this schedule?

No. All four weeks can be completed using free online platforms like DB Fiddle or SQLite Online. Week 1 specifically recommends a zero-setup option so you can start writing queries within two minutes.

Can I learn SQL in 4 weeks if I work full-time?

Yes, absolutely. The schedule assumes 30–45 minutes of daily practice. Consistency matters far more than long weekend binges. I've seen dozens of students with full-time jobs succeed because they carved out a small, non-negotiable block each evening.

Will this schedule teach me database design?

Not in depth. The focus is on querying—reading and manipulating existing data. Week 4 touches on normalization and keys through the project, but if you want to design databases from scratch, that's a separate skill you can explore after this sprint.

What if I get stuck on a concept?

Each week includes a 'debugging' tip. Additionally, SQL error messages are famously descriptive—copy the exact error text into a search engine and you'll usually find a Stack Overflow answer within seconds. Don't suffer in silence.

Is MySQL or PostgreSQL better for beginners?

Both are excellent. This schedule uses standard SQL that works on both. The choice matters less than picking one and sticking with it for the full 4 weeks. I personally started with PostgreSQL because its documentation is thorough, but MySQL's community is huge. Flip a coin—you can't go wrong.

Practical takeaway: Print this schedule. Tape it to your wall. Each evening, check off the day's task. By Day 28, you won't just know SQL—you'll have a working project and a story to tell in interviews. That's the whole point: not to memorize syntax, but to build something real.

Worth bookmarking before your next project—or sharing with a friend who keeps saying they'll learn SQL someday.