Tokenize · separate · review

Map one SQL SELECT into clauses and review flags

Tokenize a single SELECT locally, separate its retrieval, source, filter, group, order, row-bound, parameter and locking stages, and see what still requires a real database plan.

Tokenizer testedReviewed 2026-07-18

SELECT statement117 characters

Result

Your checked result will appear here.

StructuralClauses quote only the visible statement.LocalNo database or schema is contacted.Reviewed2026-07-18

Split the statement into clauses before interpreting its effect

The token strip becomes retrieval, source, filter, group, order, row-bound, parameter and locking lanes. Structural flags stay separate from the unavailable database plan.

A SQL token strip splitting into clause lanes and review flags while an execution-plan tree stays behind a guarded boundary — The local map explains what is written; the guarded tree represents plan facts only a database can supply. Original MCXAI artwork.

A bounded tokenizer makes the explanation auditable

The tool does not guess a missing schema or silently rewrite a query. Unsupported statement shapes stop with a visible error.

1Read one statement
Line and block comments are removed; strings, quoted identifiers, placeholders, parentheses and common operators remain distinct tokens.
2Enforce the SELECT boundary
WITH, compound queries, write verbs, multiple statements, nested comments and dollar-quoted strings are rejected in this version.
3Find top-level clauses
Clause keywords inside a function or subexpression do not split the outer statement because parenthesis depth remains visible.
4Report facts and flags
Counts and clause excerpts come from tokens; flags identify review questions without predicting a scan, index, cost or runtime.

Five stages from one parameterized orders query

The tested fixture contains three output expressions, one source, two filter predicates, one sort, a row limit and two placeholders. Its ordering step triggers one plan-review flag.

SELECT statement

SELECT id, status, total_cents
FROM orders
WHERE status = $1 AND total_cents >= $2
ORDER BY created_at DESC
LIMIT 50;

Explanation excerpt

# SELECT clause explanation

## Retrieval · 3 expressions
    id, status, total_cents

## Source · 1 branch
    orders

## Filtering · 2 predicates
    status = $1 AND total_cents >= $2

## Ordering
    created_at DESC

## Row bound
    LIMIT 50

## Parameters · 2

Observed: 5 stages · 3 expressions · 1 source · 2 predicates · 2 parameters · 1 flag

Write statementDELETE FROM orders WHERE id = $1;

The first token is not SELECT, so no explanation is generated inside this read-only boundary.

Flags are review prompts, not performance verdicts

A structural pattern can deserve attention without being wrong. Data distribution, indexes, statistics, engine version and workload decide the real plan.

Broad retrieval

An unqualified * asks for every visible column; compare that shape with the consumer's actual needs.

Unbounded rows

A source query without LIMIT or FETCH declares no result ceiling, even if the current table happens to be small.

Source multiplication

Multiple or comma-separated sources require a deliberate join and cardinality review.

Planner-dependent work

DISTINCT, grouping and ordering can use different strategies; inspect the target engine's plan rather than assuming one.

Move from clause map to a real execution plan carefully

EXPLAIN belongs to the database because the planner needs the actual schema, indexes, statistics, configuration and permissions.

1Choose the right engine command
PostgreSQL, MySQL and SQLite expose different plan formats and levels of detail.
2Separate estimate from execution
Plain EXPLAIN commonly shows estimates; ANALYZE-style variants can execute the statement and therefore require safer data and privileges.
3Inspect plan nodes and estimates
Look for scans, joins, sorts, temporary structures and row-estimate gaps in the context of the real workload.
4Test the revised query again
A syntactic rewrite is not an optimization until the target plan and representative execution evidence improve.

A clause map is not an execution plan

The output describes statement structure only. It does not prove correctness, authorization, result shape, index use or speed.

This version accepts one SELECT statement; WITH, compound queries, write statements, nested comments and dollar-quoted strings are outside the supported subset
The tokenizer recognizes standard quoted strings/identifiers, comments and common placeholder forms but does not validate against a dialect grammar or schema
No database is contacted, so scans, indexes, costs, row estimates, types, permissions and actual performance are unknown
Use synthetic values and a least-privileged environment when moving to database-backed plan analysis.
The Markdown download contains the current clause map and flags, not private schema metadata.
Some ANALYZE variants execute the statement; confirm the engine semantics before using them.

Preparing the page

Public context is loading before any interactive tool code.

# SELECT clause explanation ## Retrieval · 3 expressions id, status, total_cents ## Source · 1 branch orders ## Filtering · 2 predicates status = $1 AND total_cents >= $2 ## Ordering created_at DESC ## Row bound LIMIT 50 ## Parameters · 2

Start with your source

Split the statement into clauses before interpreting its effect

A bounded tokenizer makes the explanation auditable

Five stages from one parameterized orders query

Flags are review prompts, not performance verdicts

Move from clause map to a real execution plan carefully

A clause map is not an execution plan

Read plan output in the target database

Start with your source

Split the statement into clauses before interpreting its effect

A bounded tokenizer makes the explanation auditable

Five stages from one parameterized orders query

Flags are review prompts, not performance verdicts

Move from clause map to a real execution plan carefully

A clause map is not an execution plan

Read plan output in the target database