The short answer
Reformatting a SQL query never changes its results, its execution plan, or its steady-state performance — the database parser tokenizes the statement and throws away every space, tab, newline, and keyword-case choice before the query optimizer ever looks at it. Indent it, uppercase the keywords, split it across forty lines, or collapse it to one: the optimizer receives the identical parse tree and produces the identical plan. Formatting is a presentation layer for humans; the engine reads tokens, not typography.
That is the summary an AI Overview will give you, and it is correct. But it is also incomplete, because it hides the three narrow places where changing the text of a query can produce a real, observable effect — none of which contradict the rule above, all of which trip up engineers who were told "formatting is free." Below is the pipeline that makes the rule true, a table of what actually changes execution versus what doesn't, and the exact edge cases to watch.
Why formatting is invisible to the optimizer
Every SQL engine runs your text through the same front end before any optimization happens: a lexer (tokenizer) splits the raw characters into tokens — keywords, identifiers, literals, operators — and discards insignificant whitespace. A parser assembles those tokens into a syntax tree. Only then does the optimizer build an execution plan from that tree. Whitespace and keyword case exist only in the raw text; they are gone by the time any decision about indexes, joins, or scan order is made.
The dots start as two different colors (two formattings) and merge into one token stream — that convergence is the whole reason formatting is safe. Any transformation that only edits characters the tokenizer would have thrown away cannot possibly reach the optimizer.
What changes execution vs. what doesn't
| Change you make to the query | Reaches the optimizer? | Effect on results / plan |
|---|---|---|
| Indentation, tabs, blank lines | No — discarded by lexer | None |
Keyword case (SELECT vs select) | No — keywords case-insensitive | None |
| Line breaks / one-line vs multi-line | No — whitespace | None |
| Extra spaces between tokens | No — one separator is enough | None |
| Exact query text as a cache key | Cache lookup, not the plan | One-time recompile on first run (cache miss) |
Comment-based hints (/*+ INDEX(...) */) | Yes, if the formatter keeps them | Plan changes only if a bad formatter drops them |
Whitespace inside a string literal ('a b') | Yes — literal content is data | Different value → different results |
Quoted-identifier case ("Users" vs "users") | Yes — quotes preserve case | Can resolve to a different object |
| Reordering clauses, adding parentheses | Yes — that's a rewrite, not formatting | Real logic change — not what a formatter does |
The top rows are why "formatting is free" is a safe rule of thumb. The bold and lower rows are why it is not an absolute law — and every one of them is a case where you changed something other than pure whitespace, even if it looked like formatting.
The three edge cases that actually bite
1. Plan-cache miss. SQL Server, PostgreSQL, Oracle, and MySQL all cache compiled plans keyed on (roughly) the exact statement text. Reformat a frequently run query and the engine no longer finds its cached plan — it recompiles once, paying parse and optimization cost on that first execution. Nothing about the resulting plan differs; you simply moved the compile from "already done" to "now." Prepared/parameterized statements avoid this because they are planned once at prepare time.
2. Dropped comment-based hints. Oracle (/*+ ... */), MySQL hint comments, and some tools embed optimizer directives inside comments. A beautifier that discards comments will silently remove those hints, and that changes the plan — not because of whitespace, but because you deleted an instruction. Any reputable formatter, including the one linked below, preserves comments. Verify before running a formatter over hinted production SQL.
3. Whitespace inside string literals. WHERE city = 'New York' (two spaces) is a genuinely different predicate than 'New York' (one space). This is not formatting — the bytes inside the quotes are data — but auto-"cleanup" that collapses runs of spaces can corrupt literals. The rule: a formatter must never alter anything between quote marks.
The practical takeaway
Format your SQL freely for readability — consistent indentation and casing make queries reviewable and reduce copy-paste bugs, and none of it costs you at runtime. Just keep two guardrails: use a formatter that preserves comments (so hints survive), and never let any tool edit the contents of string literals. If a query slows down immediately after reformatting, run it a second time before you panic — you are almost certainly looking at a one-time plan-cache miss, not a broken query.
Want to reformat safely? Our SQL Formatter beautifies queries across MySQL, PostgreSQL, SQL Server, Oracle, SQLite, and more while leaving comments and literals untouched — so the formatted output parses to the exact same plan as your original.