SQL Query Viewer

Read a query by its tables, not its line order

SQL puts the output first and the data source second. In a long report query the SELECT list fills the top half of the screen, the tables hide in the middle, and the join conditions sit next to tables they do not belong to. You end up scrolling up and down to answer one question: where does this number come from?

The viewer answers by drawing the query instead of reformatting the text. Each table becomes a card listing only the columns this query touches, tagged by what the query does with them. Each join becomes a line from the parent table to the joined table, anchored on the actual key columns and colored by join type. The driving table sits on the left, and every hop to the right is one more join away from the start.

Three situations where this view saves time:

• Reviewing a pull request adding a fifth join to a reporting query. The diagram shows whether the new table attaches to the right parent, or to the line items, where the join multiplies row counts.
• Reading ORM output from a Laravel or Django query log. Generated SQL arrives on one line with quoted identifiers everywhere. The cards strip the noise and show the shape.
• Inheriting a database with no documentation. Paste the output of pg_dump --schema-only or mysqldump --no-data and the foreign keys come back as a schema map.

Written order versus run order

The database never reads your query top to bottom. Logically, the engine builds the row set first, then filters, then groups, and only then computes the SELECT list. The Run order tab lays out your own query in this sequence, with the written position next to each step.

This table explains the most common SQL error people search for. Write WHERE revenue > 500 where revenue is a SELECT alias, and PostgreSQL replies with column "revenue" does not exist, while MySQL reports Unknown column 'revenue' in 'where clause'. The alias is born at step 5, three steps after WHERE runs. The review panel flags this before you hit run.

One caution. This is the logical order, the one which decides what each clause sees. The query planner is free to reorder joins and push filters down for speed. For the physical plan, run EXPLAIN in PostgreSQL or MySQL, or turn on the actual execution plan in SQL Server Management Studio.

What the review panel flags

The checks look for patterns which run without errors and still return the wrong rows, or the right rows slowly. Each finding names the clause involved.

A LEFT JOIN quietly turned into an INNER JOIN

This one survives code review because the query looks right. A LEFT JOIN keeps stores with no reviews by filling the review columns with NULL. A WHERE filter on those columns then throws the NULL rows away, and the stores you meant to keep vanish.

SELECT s.name, r.rating
FROM stores s
LEFT JOIN reviews r ON r.store_id = s.id
WHERE r.rating >= 4;

SELECT s.name, r.rating
FROM stores s
LEFT JOIN reviews r ON r.store_id = s.id
                   AND r.rating >= 4;

Load the LEFT JOIN trap sample above to see the warning on a live query.

The rest of the list

• A join with no condition. A comma-separated table never tied to the others in WHERE, or a JOIN missing its ON. Two tables of 1,000 rows return 1,000,000. The Comma join sample shows one.
• An output alias used in WHERE. Covered above. The query fails at run time on every major engine.
• NOT IN over a subquery. One NULL in the subquery result makes the whole predicate unknown, and the query returns zero rows with no error. NOT EXISTS does not have this problem.
• A function wrapped around a filtered column. WHERE YEAR(placed_at) = 2026 forces a calculation on every row and skips a plain index on placed_at. A date range does the same job with the index.
• A leading wildcard. LIKE '%mart' has no prefix to seek on, so the database scans the full table.
• LIMIT or TOP without ORDER BY. The rows you get depend on storage order and the plan of the day. Pagination built on this repeats and skips rows.
• UPDATE or DELETE without WHERE. Flagged as an error, since the statement rewrites or empties the whole table.
• An INSERT with no column list, which breaks the day someone adds a column to the target table.

Paste CREATE TABLE statements for a schema map

Give the viewer a script of CREATE TABLE statements and the diagram switches to schema mode. Every column shows its declared type, primary keys get a PK badge, and each foreign key draws a line from the referenced table to the referencing one. With more than one table in the script, a Whole schema entry appears first in the statement menu so you see every relationship on one board.

Foreign keys added later through ALTER TABLE ... ADD FOREIGN KEY are picked up too, which matters for PostgreSQL dumps, since pg_dump writes constraints as separate ALTER statements after all the tables. A table referenced by a key but never created in the script still appears, with a dashed outline and a note, so a missing dependency is obvious before you run the script on an empty database.

Load the Schema DDL sample to see four tables from an order system laid out by dependency: customers and products on the left, order lines on the far right.

Where this viewer stops

The viewer reads the text of your SQL. There is no database connection, which keeps your data private and also sets hard limits.

• No schema knowledge. A column written without a table prefix in a multi-table query has no known owner, so the diagram leaves the column off and the review panel lists the name. Prefix every column with its alias and the cards fill in completely.
• No row counts or indexes. The checks spot risky shapes. They have no idea whether orders holds 200 rows or 200 million, so a flagged leading wildcard on a tiny lookup table is harmless.
• Subqueries stay closed. A subquery in FROM shows as one card with its output columns. Subqueries inside WHERE are counted, not drawn. CTEs get their own entry in the statement menu instead.
• Procedural code is skipped. Function bodies in PL/pgSQL, T-SQL BEGIN ... END blocks, cursors and dynamic SQL built from strings fall outside the diagram. MERGE statements are listed without a drawing.
• Big dumps slow the page. Every pause in typing re-reads the whole script. A schema of a few hundred tables is fine. A dump full of INSERT rows is not, so export with --no-data or --schema-only first.
• Large diagrams get wide. Past roughly a dozen tables the board scrolls sideways. Use the statement menu or paste one query at a time for a tighter view.

For layout only, without a diagram, the SQL Formatter rewrites the same query with consistent indentation.