Master the 5 SQL skills every business analyst needs. From practical queries to interview prep, learn exactly what BAs need to know.
Jump into the SQLNoir case files and put these tips to work.
If you're a business analyst avoiding SQL, you're leaving insights on the table. Let's fix that.
Yes. According to LinkedIn's 2024 Jobs Report, over 65% of business analyst job postings list SQL as a required or preferred skill. That number has grown steadily over the past five years and shows no signs of slowing down. In 2026, SQL for business analysts isn't optional. It's expected.
But here's the good news: the SQL skills you need as a BA are different from what developers use. You're not building databases or writing complex stored procedures. You're extracting answers from existing data. Your SQL is read-focused, not write-focused.
Business analysts who know SQL can answer stakeholder questions in minutes instead of waiting days for the data team. That speed creates massive competitive advantage in fast-moving organizations.
When you can pull your own data, you control your timeline. You can explore hypotheses immediately, iterate on reports without dependencies, and bring concrete numbers to every meeting. SQL transforms you from someone who requests data into someone who discovers insights.
Business analysts and data analysts both use SQL, but their daily queries look quite different. Understanding this distinction helps you focus your learning on what actually matters for your role.
What BAs can skip: Stored procedures, database administration, query optimization, indexing strategies, and complex window functions. These are valuable skills, but they're not essential for your day-to-day work.
What BAs must master: SELECT statements, WHERE clauses, JOINs (especially INNER and LEFT), GROUP BY with aggregations, and basic date functions. These five areas will handle 90% of your queries.
If you want to practice these SQL patterns hands-on, SQLNoir's detective cases let you write the same JOINs, aggregations, and multi-table queries by solving crime mysteries — the SQL skills transfer directly to the stakeholder questions and data exploration tasks you'll face as a BA.
Let's break down each essential SQL skill for business analysts with practical examples you can use immediately.
Every query starts with SELECT. Combined with WHERE, AND, OR, and IN, you can extract exactly the data you need from any table.
SELECT customer_name, email, signup_date
FROM customers
WHERE status = 'active'
AND plan_type IN ('enterprise', 'business')
AND signup_date >= '2024-01-01';This query filters customers by multiple conditions: active status, specific plan types, and recent signup dates.
Aggregations turn raw data into business metrics. COUNT tells you how many, SUM gives you totals, and AVG provides averages. GROUP BY lets you calculate these metrics for different categories.
SELECT
region,
COUNT(*) AS total_orders,
SUM(order_amount) AS total_revenue,
AVG(order_amount) AS avg_order_value
FROM orders
GROUP BY region
ORDER BY total_revenue DESC;GROUP BY region creates separate calculations for each geographic area, while ORDER BY sorts results by revenue.
JOINs connect data from multiple tables. INNER JOIN returns only matching records from both tables. LEFT JOIN returns all records from the left table plus matching records from the right. These two JOINs cover 90% of business analyst needs.
SELECT
c.customer_name,
c.email,
o.order_id,
o.order_date,
o.order_amount
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= '2024-01-01';INNER JOIN connects customers to their orders using the shared customer_id field. Only customers with orders appear in results.
Business reporting lives and dies by dates. You need to filter by time periods, extract months or years, and calculate date differences. Syntax varies by database, but the concepts remain consistent.
SELECT
DATE_TRUNC('month', order_date) AS month,
COUNT(*) AS total_orders,
SUM(order_amount) AS monthly_revenue
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY DATE_TRUNC('month', order_date)
ORDER BY month;DATE_TRUNC truncates dates to the specified precision. In MySQL, you would use DATE_FORMAT(order_date, '%Y-%m') instead.
Subqueries let you nest one query inside another. They're essential for answering complex business questions that require multiple steps, like finding customers who exceed the average order value.
SELECT customer_name, email, total_spent
FROM customers
WHERE total_spent > (
SELECT AVG(total_spent)
FROM customers
);The inner query calculates the average, then the outer query uses that value to filter results.
Theory is great, but let's look at four real scenarios you'll encounter as a business analyst. Each query solves a common business question.
Your sales director wants to know top performers for the quarterly review. This requires GROUP BY to aggregate by product and ORDER BY to rank results.
SELECT
p.product_name,
p.category,
COUNT(oi.order_item_id) AS units_sold,
SUM(oi.quantity * oi.unit_price) AS total_revenue
FROM order_items oi
INNER JOIN products p ON oi.product_id = p.product_id
INNER JOIN orders o ON oi.order_id = o.order_id
WHERE o.order_date >= '2024-10-01'
AND o.order_date < '2025-01-01'
GROUP BY p.product_id, p.product_name, p.category
ORDER BY total_revenue DESC
LIMIT 10;This joins three tables to connect order items with product details and filter by date range. The LIMIT 10 gives you just the top performers.
Marketing wants to identify loyal customers for a rewards program. This is a classic LEFT JOIN with NULL check pattern.
SELECT
c.customer_id,
c.customer_name,
c.email,
COUNT(o.order_id) AS total_orders,
SUM(o.order_amount) AS lifetime_value
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id
LEFT JOIN returns r ON o.order_id = r.order_id
WHERE r.return_id IS NULL
GROUP BY c.customer_id, c.customer_name, c.email
HAVING COUNT(o.order_id) >= 3
ORDER BY lifetime_value DESC;LEFT JOIN includes all orders whether they have returns or not. WHERE r.return_id IS NULL filters to only those without returns. HAVING filters after aggregation.
Finance needs a trend report showing how revenue changes each month. This combines date functions with aggregations.
WITH monthly_revenue AS (
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(order_amount) AS revenue
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY DATE_TRUNC('month', order_date)
)
SELECT
month,
revenue,
LAG(revenue) OVER (ORDER BY month) AS prev_month_revenue,
ROUND(
(revenue - LAG(revenue) OVER (ORDER BY month)) /
LAG(revenue) OVER (ORDER BY month) * 100,
2
) AS growth_percentage
FROM monthly_revenue
ORDER BY month;The CTE (WITH clause) calculates monthly totals first. LAG() accesses the previous row's value to calculate growth. This is slightly advanced but incredibly useful for trend analysis.
The regional sales team needs customer counts and order totals broken down by geography. This requires joining multiple tables and grouping by region.
SELECT
r.region_name,
COUNT(DISTINCT c.customer_id) AS total_customers,
COUNT(o.order_id) AS total_orders,
SUM(o.order_amount) AS total_revenue,
ROUND(SUM(o.order_amount) / COUNT(DISTINCT c.customer_id), 2) AS revenue_per_customer
FROM regions r
INNER JOIN customers c ON r.region_id = c.region_id
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY r.region_id, r.region_name
ORDER BY total_revenue DESC;COUNT(DISTINCT customer_id) prevents counting the same customer multiple times when they have multiple orders. LEFT JOIN ensures regions appear even if they have customers with no orders.
Practice the Same SQL Patterns with Detective Cases
The JOINs, GROUP BY, and aggregations you just learned work identically whether you're analyzing business data or solving crimes. SQLNoir gives you real databases to query — you'll write multi-table queries, find patterns, and build the SQL muscle memory every BA needs.
SQL questions are standard in BA interviews. Here are common questions with approaches you can adapt.
SELECT MAX(salary) AS second_highest FROM employees WHERE salary < (SELECT MAX(salary) FROM employees);
The subquery finds the maximum salary, then the outer query finds the maximum of everything below that.
SELECT email, COUNT(*) AS count FROM customers GROUP BY email HAVING COUNT(*) > 1;
GROUP BY email collapses duplicate emails, HAVING filters to only those appearing more than once.
SELECT
d.department_name,
COUNT(e.employee_id) AS employee_count
FROM departments d
LEFT JOIN employees e ON d.department_id = e.department_id
GROUP BY d.department_id, d.department_name
HAVING COUNT(e.employee_id) > (
SELECT AVG(dept_count)
FROM (
SELECT COUNT(*) AS dept_count
FROM employees
GROUP BY department_id
) AS dept_counts
);The nested subquery calculates the average department size, then HAVING compares each department against that average.
SELECT DISTINCT c.customer_id, c.customer_name
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id
WHERE YEAR(o.order_date) = 2023
AND c.customer_id NOT IN (
SELECT customer_id
FROM orders
WHERE YEAR(order_date) = 2024
);NOT IN excludes customers who appear in the 2024 orders subquery.
Talk through your approach before writing code. Interviewers want to see your thought process. Start with "I would use a GROUP BY with HAVING because..." and explain your logic. Even if your syntax isn't perfect, showing clear thinking matters more than memorized queries.
Learning SQL for business analytics doesn't require months of study. With focused practice, you can build job-ready skills in six weeks.
Goal: Write queries that filter and sort data from a single table confidently.
Goal: Connect multiple tables and calculate business metrics by category.
Even experienced analysts make these errors. Knowing what to watch for helps you avoid embarrassing data mistakes.
NULL doesn't equal anything, not even itself. Comparisons with NULL always return unknown, which usually means your row gets excluded.
SELECT * FROM customers WHERE region != 'West';
This excludes customers with NULL regions, even though NULL is not 'West'.
SELECT * FROM customers WHERE region != 'West' OR region IS NULL;
Explicitly include NULL values when they should appear in results.
JOINs can multiply your rows unexpectedly. If a customer has 5 orders and each order has 3 items, joining all three tables gives you 15 rows per customer.
Always check your row count before and after JOINs. Use COUNT(DISTINCT customer_id) when you need unique counts. When something seems off, SELECT * with LIMIT 100 and eyeball the data.
Running a query on millions of rows before testing it on a small sample wastes time and can crash systems. Always add a LIMIT clause or date filter during development.
-- During development, add a LIMIT SELECT * FROM large_table WHERE conditions LIMIT 100; -- Or filter to recent data only SELECT * FROM large_table WHERE created_date >= CURRENT_DATE - INTERVAL '7 days';
Dates and timestamps often have hidden time zone issues. A report showing "January sales" might include or exclude December 31st depending on how timestamps are stored and converted.
Always confirm how dates are stored in your database, whether as UTC, local time, or timestamp with time zone. When in doubt, ask your data engineering team.
Build SQL Muscle Memory with Detective Cases
You've learned the syntax — JOINs, aggregations, date functions, and subqueries. Now practice those exact same patterns by querying real databases. The SQL skills you drill solving mysteries in SQLNoir transfer directly to stakeholder meetings, KPI reports, and business analysis work.
Start Your Investigation →SQL for business analysts comes down to five core skills: SELECT with filtering, aggregations, JOINs, date functions, and subqueries. Master these, and you'll handle 90% of the data questions that come your way.
The best time to learn SQL was five years ago. The second best time is now. Start with simple queries, build toward complex ones, and practice consistently.