SQL Cheat Sheet: Commands, Clause Order and Dialects

TL;DR: This SQL cheat sheet puts the commands you look up most in one table, then shows the order SQL actually runs clauses in, joins, aggregates, window functions and CTEs. Where PostgreSQL, MySQL and SQL Server disagree (row limits, upserts, string matching), the syntax is shown side by side so you can copy the version your database accepts.

A SQL cheat sheet is a one-page reference of SQL statement syntax. The core SQL commands cheat sheet fits in five groups: querying (SELECT, WHERE, GROUP BY, HAVING, ORDER BY), changing data (INSERT, UPDATE, DELETE, MERGE), defining structure (CREATE, ALTER, DROP), controlling access (GRANT, REVOKE) and transactions (BEGIN, COMMIT, ROLLBACK). Most mistakes come from two things this page covers early: the order clauses are evaluated in, and the dialect differences between PostgreSQL, MySQL and SQL Server.

SQL statement cheat sheet: the lookup table

What are the basic SQL commands?

The basic SQL commands are SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER and DROP. They split into DQL/DML (reading and changing rows) and DDL (changing structure), with GRANT/REVOKE (DCL) and COMMIT/ROLLBACK (TCL) completing the set. A typical analytical query uses only SELECT with its clauses:

SELECT country, COUNT(*) AS customers, SUM(mrr) AS total_mrr
FROM customers
WHERE status = 'active'
GROUP BY country
HAVING SUM(mrr) > 1000
ORDER BY total_mrr DESC
LIMIT 10;

What is the order of SQL clauses?

SQL is written in one order and evaluated in another. You write SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT, but the database logically processes them like this:

This explains the most common error: you cannot use a SELECT alias in WHERE, because WHERE runs first. ORDER BY can use the alias because it runs after. It also explains why you filter aggregates with HAVING, not WHERE. For a deeper look at filtering, see our guide to CASE WHEN in PostgreSQL.

Joins cheat sheet

-- customers with no orders
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

MySQL has no FULL OUTER JOIN; emulate it with a LEFT JOIN UNION a RIGHT JOIN. Joining when you only need columns from several tables without a key is covered in selecting from multiple tables without JOIN.

What differs between MySQL and PostgreSQL syntax?

The core of SQL is portable; row limits, upserts, string handling and identifiers are not. These are the differences you hit most:

-- PostgreSQL upsert
INSERT INTO plans (id, price) VALUES (1, 30)
ON CONFLICT (id) DO UPDATE SET price = EXCLUDED.price
RETURNING *;

-- MySQL upsert
INSERT INTO plans (id, price) VALUES (1, 30)
ON DUPLICATE KEY UPDATE price = 30;

Version notes worth knowing: ILIKE is a PostgreSQL extension, not standard SQL (PostgreSQL docs). PostgreSQL got MERGE in version 15 (release notes). In SQL Server, TOP ... WITH TIES requires ORDER BY and can return more rows than asked for when the last value ties (Microsoft Learn). In every dialect, a row limit without ORDER BY returns an unpredictable subset, and rows skipped by a large OFFSET are still computed by the server (PostgreSQL docs). Date functions differ most of all; see GETDATE in PostgreSQL and DATEDIFF in PostgreSQL.

How do window functions work?

A window function computes a value for each row from a set of related rows (the window) without collapsing them the way GROUP BY does. You define the window with OVER (PARTITION BY ... ORDER BY ...). They are supported in PostgreSQL, MySQL 8.0 and later, SQL Server and SQLite 3.25.0 and later (SQLite docs).

-- latest order per customer
SELECT *
FROM (
  SELECT o.*, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC) AS rn
  FROM orders o
) x
WHERE rn = 1;

Window functions run at the SELECT step, so you cannot filter on them in WHERE; wrap the query as above. More patterns in our PARTITION BY guide.

CTEs (WITH queries)

A common table expression is a named subquery defined with WITH that exists for one statement. It makes multi-step logic readable, and WITH RECURSIVE walks hierarchies such as org charts or category trees.

WITH monthly AS (
  SELECT date_trunc('month', created_at) AS month, SUM(amount) AS revenue
  FROM orders
  GROUP BY 1
)
SELECT month, revenue,
       revenue - LAG(revenue) OVER (ORDER BY month) AS change
FROM monthly
ORDER BY month;

In PostgreSQL a non-recursive CTE referenced once is inlined into the main query; add MATERIALIZED or NOT MATERIALIZED after AS to override that (PostgreSQL docs). MySQL supports CTEs from 8.0. date_trunc is PostgreSQL; in MySQL use DATE_FORMAT(created_at, '%Y-%m-01').

Common mistakes the cheat sheet saves you from

• WHERE col = NULL returns nothing; use IS NULL.
• COUNT(col) and COUNT(*) differ when col has NULLs.
• NOT IN (subquery) returns no rows if the subquery contains a NULL; use NOT EXISTS.
• A LEFT JOIN turns into an inner join when you filter the right table in WHERE; move that condition into ON.
• Joining two one-to-many tables multiplies rows and inflates SUM; aggregate each side in a CTE first. Duplicate rows are easy to find with this duplicates query.

When you'd rather not write the query

A cheat sheet helps when you know SQL and forget syntax. When the person with the question is in ops, sales or finance, the bottleneck is the query itself. AI for Database connects to PostgreSQL, MySQL, SQL Server and other sources, answers plain-English questions with the SQL it ran shown next to the result, and can pin the answer to a self-refreshing dashboard or an alert. Try AI for Database free at aifordatabase.com, sample data included.