SQL Cheat Sheet for Data Analysts 2026 — Free PDF Download

Quick Answer: This SQL cheat sheet covers every command a Data Analyst needs — SELECT, WHERE, GROUP BY, all JOIN types, window functions, subqueries, CTEs, and performance tips. The free PDF is a printable 2-page reference sheet used by 1,500+ GROWAI students.
📋

SELECT & Filters

🔗

All JOIN Types

📊

GROUP BY & Aggregates

🪟

Window Functions

🔄

Subqueries & CTEs

Performance Tips

What’s in the Free PDF Cheat Sheet

  • Complete SQL command reference with syntax and real examples
  • All 6 JOIN types with visual diagrams (INNER, LEFT, RIGHT, FULL, CROSS, SELF)
  • Window functions: ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, NTILE
  • 20 most-used aggregate functions with examples
  • CTE vs Subquery — when to use which (with performance notes)
  • Interview-ready: common SQL patterns asked in tech company interviews

Preview: Core SQL Commands

-- Basic SELECT with filtering
SELECT customer_id, name, city, total_orders
FROM customers
WHERE city = 'Bangalore'
  AND total_orders > 5
  AND signup_date >= '2024-01-01'
ORDER BY total_orders DESC
LIMIT 100;

-- Using LIKE, IN, BETWEEN
SELECT * FROM products
WHERE category IN ('Electronics', 'Mobiles')
  AND price BETWEEN 10000 AND 50000
  AND name LIKE '%Samsung%';
-- Sales by city with HAVING filter
SELECT
  city,
  COUNT(*) AS total_customers,
  SUM(revenue) AS total_revenue,
  AVG(revenue) AS avg_revenue,
  MAX(revenue) AS top_revenue
FROM orders
GROUP BY city
HAVING COUNT(*) > 100
ORDER BY total_revenue DESC;
-- INNER JOIN: only matching rows
SELECT o.order_id, c.name, o.amount
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;

-- LEFT JOIN: all from left + matched from right
SELECT c.name, o.order_id, o.amount
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id;
-- customers with no orders will show NULL for order columns

-- FULL OUTER JOIN: all rows from both tables
SELECT * FROM table_a
FULL OUTER JOIN table_b ON table_a.id = table_b.id;
-- ROW_NUMBER: unique rank per partition
SELECT
  name, department, salary,
  ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) AS rank_in_dept,
  LAG(salary) OVER (PARTITION BY department ORDER BY hire_date) AS prev_salary,
  LEAD(salary) OVER (PARTITION BY department ORDER BY hire_date) AS next_salary
FROM employees;

Download the Full Cheat Sheet — Free

Printable 2-page PDF covering all SQL commands, window functions, CTEs, and interview patterns. Used by 1,500+ GROWAI students.




No spam. PDF link sent via WhatsApp in under 2 minutes.

-- CTE (Common Table Expression)
WITH top_customers AS (
  SELECT customer_id, SUM(amount) AS total
  FROM orders
  GROUP BY customer_id
  HAVING SUM(amount) > 100000
)
SELECT c.name, t.total
FROM customers c
JOIN top_customers t ON c.id = t.customer_id;
🔒 CTEs, subqueries, performance tips and more are in the free PDF. Download above.

Frequently Asked Questions

What SQL commands do Data Analysts use most often?+
The most commonly used SQL commands for Data Analysts are: SELECT with complex WHERE clauses, GROUP BY with aggregates (SUM, COUNT, AVG), JOINs (especially LEFT and INNER), window functions (ROW_NUMBER, RANK, LAG/LEAD), CTEs for complex queries, and CASE WHEN for conditional logic.
What is the difference between RANK() and DENSE_RANK() in SQL?+
RANK() skips numbers after ties — if two rows tie for rank 2, the next rank is 4. DENSE_RANK() does not skip — the next rank after two rows tied at 2 would be 3. Data Analysts use DENSE_RANK() more often when they want consecutive rankings without gaps.
When should I use a CTE instead of a subquery?+
Use CTEs when: (1) you need to reference the same subquery multiple times, (2) your query has more than 2 levels of nesting, (3) you want to improve readability for complex logic. Use subqueries for simple, one-off filters in WHERE or FROM clauses. CTEs also support recursive queries.
How do I improve SQL query performance?+
Key performance tips: (1) Always filter early using WHERE before joining, (2) Use indexes on columns used in WHERE and JOIN conditions, (3) Avoid SELECT * — only fetch needed columns, (4) Use EXISTS instead of IN for large subqueries, (5) Partition large tables and query specific partitions, (6) Use EXPLAIN/EXPLAIN ANALYZE to understand query plans.