Skip to content
← Back

SQL Cheatsheet - Online Tool

Code
Runs locally · Not uploaded

Handy SQL Cheatsheet for developers: covers queries, aggregations, joins, subqueries, and window functions. Searchable and categorized for quick reference. All local processing.

Was this result helpful?

For local tools, open DevTools → Network and search your input — it should not appear in requests.

Usage Guide

SQL cheatsheet: SELECT / JOIN / aggregation / subquery / window functions — syntax and examples sorted by frequency. Local static page, no network lookup. Built for quick syntax reference while writing queries, interview prep, or as a team handbook.

1. How to use

  1. Find the syntax by category (basic queries / multi-table joins / aggregations).
  2. Read the example, copy, swap in your table and column names.
  3. Pair with the sql-formatter tool to prettify long queries before reading.

2. Frequent scenarios

  • Multi-table joins: INNER JOIN for intersection, LEFT JOIN to keep all left rows — do not confuse them.
  • Grouped stats: GROUP BY + COUNT/SUM/AVG, filter groups with HAVING.
  • Deduplication: DISTINCT or GROUP BY — the latter is more flexible but slightly slower.

3. A performance note

Applying functions to columns in WHERE (e.g. WHERE YEAR(create_time)=2026) kills the index — rewrite as a range (WHERE create_time BETWEEN ...). Same for LIKE '%xxx%' with a leading wildcard. Run EXPLAIN to see the execution plan; type=ALL means full table scan and must be optimized.

4. Reading execution plans before blaming the query

Most slow queries are not slow because of syntax but because of what the engine does with it. Run EXPLAIN before your SELECT and read two fields first: type (ALL means a full table scan — usually the problem) and rows (how many rows the engine expects to touch). An index that looks present but unused is the classic trap: functions on columns in WHERE, LIKE with a leading wildcard, and mismatched column types between JOIN tables all silently disable indexes. Fix the shape of the predicate rather than adding more indexes — each extra index taxes every INSERT and UPDATE.

FAQ

Never — this is a static syntax reference. It connects to no database and runs none of the statements you write.

Common syntax with short examples, organized by SELECT, JOIN, aggregation, subqueries, window functions, and date handling — handy mid-query, for interview prep, or as an onboarding reference.

They lean toward generic dialect SQL. LIMIT versus TOP, string concatenation, date functions, and boolean literals often differ between vendors — double-check against your target database, and in interviews follow the interviewer's dialect.

Filtering after aggregation belongs in HAVING, not WHERE; putting the JOIN condition into WHERE silently turns a LEFT JOIN into an INNER JOIN; and SELECT * doesn't belong in production reports.

Start with single-table filtering and sorting, then JOINs and NULL behavior, GROUP BY with aggregates, then the subquery-versus-CTE tradeoff, and finally window functions for ranking and running totals. Getting JOINs and grouping right first means far less rework.

Run a minimal sample with fake data in the SQL Playground; tidy long statements with the SQL formatter, sketch tables with the SQL table generator, and convert Markdown tables straight into SQL.

Related Tools

Related Articles