Build SQL queries visually by defining your schema and selecting columns, joins, and filters — or paste an existing query to get a plain-English explanation, performance analysis, and optimization suggestions. Everything runs in your browser.
Pro tip: In Build mode, define your tables and columns first, then select which columns to include in your query. Switch to Explain mode to analyze complex queries you encounter in production code.
How to Use the SQL Query Builder
The SQL Query Builder operates in two complementary modes. In Build mode, you define your database schema by adding tables and their columns, then visually construct queries by selecting columns, adding JOIN conditions, applying WHERE filters, and setting ORDER BY and LIMIT clauses. The tool generates valid SQL in real time as you configure each option, so you can see your query take shape incrementally. This is especially useful when learning SQL syntax or when you need to prototype a query against a schema you are still designing.
In Explain mode, paste any SQL query and get a plain-English explanation
of what the query does, a prettified version with proper indentation and syntax highlighting,
and a detailed performance analysis. The tool identifies common anti-patterns like
SELECT * usage, missing WHERE clauses on large joins, correlated subqueries,
and leading-wildcard LIKE patterns. Each issue includes an explanation of why it is
problematic and a suggested alternative.
Understanding SQL Joins
Joins are one of the most powerful features of SQL and also one of the most commonly misunderstood. An INNER JOIN returns only rows that have matching values in both tables. A LEFT JOIN returns all rows from the left table and matching rows from the right table; where there is no match, the right columns contain NULL values. RIGHT JOIN works the same way but in reverse. A FULL OUTER JOIN returns all rows from both tables, filling in NULLs on whichever side lacks a match. Understanding which join type to use determines whether your query returns only intersecting data or includes rows that exist in one table but not the other.
A common performance mistake is joining tables without a WHERE clause, which can produce a Cartesian product where every row in one table is combined with every row in the other. On tables with thousands of rows, this can produce millions of result rows and bring your database server to a halt. The query builder warns you about this pattern and suggests adding appropriate filtering conditions.
Reading a Query Complexity Score
The complexity score ranges from 0 to 100 and is calculated based on the number of tables involved, the types and depths of joins, the number and nesting of WHERE conditions, the presence of subqueries, aggregate functions, GROUP BY clauses, and HAVING filters. A score below 20 indicates a simple single-table query. Scores between 20 and 50 typically involve one or two joins with straightforward filtering. Scores above 50 signal queries that may benefit from optimization review, and anything above 75 represents complex analytical queries that should be carefully evaluated for performance before running against production data.
Common SQL Performance Anti-Patterns
Several SQL patterns are technically correct but perform poorly at scale.
SELECT * forces the database to retrieve every column, including large
text or blob fields you may not need, increasing I/O and memory usage. Replacing it with
an explicit column list lets the query optimizer use covering indexes. Leading
wildcard LIKE patterns such as LIKE '%search' prevent the use of
B-tree indexes entirely, forcing a full table scan. When possible, restructure these
queries to use full-text search indexes or suffix the wildcard instead:
LIKE 'search%'.
Correlated subqueries execute once for every row in the outer query,
turning what looks like a simple filter into an O(n×m) operation. Converting them to
JOINs or using EXISTS with a correlated subquery often reduces execution time by orders
of magnitude. Non-sargable predicates — conditions that wrap a
column in a function, like WHERE YEAR(created_at) = 2024 — prevent
index usage because the database must evaluate the function for every row. Rewriting to
a range condition (WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01')
allows the optimizer to use an index seek.
Index Optimization Strategies
Indexes are the single most impactful performance optimization for SQL queries. The tool suggests indexes based on the columns used in WHERE clauses, JOIN conditions, and ORDER BY clauses. A composite index covering multiple columns can satisfy a query without ever touching the table data (a covering index). The order of columns in a composite index matters: put the most selective column (the one that filters out the most rows) first. For queries that both filter and sort, include the WHERE columns before the ORDER BY columns in the index definition.
However, indexes are not free. Each index adds overhead to INSERT, UPDATE, and DELETE operations because the database must maintain the index alongside the table data. Over-indexing a write-heavy table can degrade overall performance. The tool provides index suggestions as starting points; always validate them with your actual query execution plans and workload characteristics using EXPLAIN or EXPLAIN ANALYZE.
Multi-Dialect SQL Differences
While SQL is standardized (ANSI SQL), every database engine extends the standard with
proprietary syntax. MySQL uses backtick quoting for identifiers and
LIMIT n for row limiting. PostgreSQL uses double-quote
quoting and supports LIMIT n natively with additional OFFSET
support. SQL Server uses square brackets for identifiers and requires
TOP n or OFFSET-FETCH syntax for row limiting. Oracle
traditionally used ROWNUM in a wrapping query but now supports
FETCH FIRST n ROWS ONLY in recent versions. SQLite follows
MySQL-like syntax for most operations but has a more limited type system.
The Multi-Dialect Translator (available to subscribers) converts your query between these five dialects, highlighting the specific syntax changes so you can see exactly what differs. This is invaluable when migrating between database platforms or writing applications that must support multiple backends.
Best Practices for Writing Maintainable SQL
Beyond performance, writing SQL that other developers can read and maintain is equally important. Always alias your tables with meaningful short names and qualify every column reference with its table alias, even when there is no ambiguity — this prevents breakage when new columns are added to tables later. Use consistent indentation and place each major clause (SELECT, FROM, JOIN, WHERE, ORDER BY) on its own line. Comment complex logic inline so future readers understand the business reasoning behind non-obvious conditions.
For additional developer tools, check out the JSON Formatter for working with API response data, or the Regex Tester for building patterns used in SQL LIKE and REGEXP clauses.
Frequently Asked Questions
Why is SELECT * considered an anti-pattern?
It forces the database to return every column, which increases I/O, breaks covering index optimizations, and silently changes application behavior when the schema evolves. Always list the columns you actually need, per the guidance in Joe Celko's SQL style rules.
What is the difference between INNER JOIN and LEFT JOIN?
INNER JOIN returns only rows with a match in both tables, while LEFT JOIN returns all rows from the left table and nulls for missing right-side rows. Using LEFT JOIN when you mean INNER JOIN is a common source of accidentally inflated result sets.
Why are correlated subqueries slow?
A correlated subquery re-evaluates once per outer row, turning what should be an O(n) scan into O(n squared). Most can be rewritten as a single JOIN or a window function. Modern optimizers sometimes unnest them, but not always, so it is safer to rewrite by hand.
Does LIKE '%foo' use indexes?
No. Leading-wildcard LIKE patterns cannot use a standard B-tree index because the index is sorted from the left. Use trigram indexes (pg_trgm in PostgreSQL), full-text search, or a dedicated search engine like Elasticsearch for substring matching at scale.
When should I use a CTE instead of a subquery?
CTEs (WITH clauses) improve readability when a subquery is used more than once or when expressing a recursive query. In modern PostgreSQL, MySQL 8, and SQL Server, the optimizer usually inlines non-recursive CTEs, so performance is equivalent. Prefer them for clarity.