SQL Query Builder

Logically a SELECT is evaluated as FROM and JOIN, then WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY and finally LIMIT / OFFSET. That is why WHERE cannot use aggregates or column aliases, HAVING can use aggregates, and ORDER BY can use the aliases from SELECT.

WHERE filters individual rows before they are grouped, so it cannot use functions like COUNT or SUM. HAVING filters the groups after GROUP BY, for example HAVING COUNT(o.id) >= 2 to keep only customers with at least two orders.

INNER JOIN returns only rows that have a match in both tables. LEFT JOIN returns every row of the left table and fills the right table's columns with NULL where there is no match, so customers without orders still appear with a count of 0.

When rows are grouped, each output row stands for many input rows, so a plain column must have one value per group. Standard SQL requires it to be in GROUP BY (PostgreSQL allows columns that depend on a grouped primary key, and MySQL's ONLY_FULL_GROUP_BY mode enforces the rule). The builder adds them automatically.

SQL Server has no LIMIT. The builder uses SELECT TOP (n) for a plain limit, and ORDER BY … OFFSET n ROWS FETCH NEXT m ROWS ONLY when you also skip rows. OFFSET requires an ORDER BY clause.

Numbers compared with numeric columns stay unquoted, other values become string literals with single quotes doubled for safety. IN lists are split on commas. Values like :name, ?, $1 or @param are kept as parameter placeholders, which is what you should use in application code to avoid SQL injection.

No. It only writes the SQL text in your browser. Run it in your database client, or try it on a CSV file with the Query CSV with SQL tool.

Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.