MySQL Query Beautifier
Every character you typed survives -- this pass changes layout, never content. Auto and MySQL / MariaDB share the readings MySQL means: a bare # is a line comment and backslashes inside single quotes escape the next character. The layout is engine-agnostic in every mode: backtick identifiers, LIMIT 10, 20, ON DUPLICATE KEY UPDATE and GROUP_CONCAT(x SEPARATOR ...) keep their shape through formatting and minifying, and the JSONB-looking operators #>, #>> and #- stay recognised so pasted Postgres casts never truncate your query. Minify deletes comments instead of compressing them.
What picking MYSQL / MARIADB actually does
Auto and MYSQL / MARIADB produce byte-identical output on every probe below, so picking MYSQL / MARIADB does not change how this formatter reads your query — Auto already guesses the way MySQL does. The box still matters for the queries it guesses about: two spellings mean opposite things in two engines, and a formatter that cannot ask has to pick one. Those are the cases here, shown from this mode and from the modes that read them differently.
A bare # between two operands
PostgreSQL spells integer bitwise XOR with #. MySQL reads the same byte as a line comment running to end of line. No parser can tell the two apart from the text alone, so the mode you pick decides which one survives.
Typed in
SELECT a # b FROM t;
Formatted in MYSQL / MARIADB mode
SELECT a # b FROM t;
The same text in PostgreSQL mode
SELECT a # b FROM t;
Minified in MYSQL / MARIADB mode
SELECT a
Minified in PostgreSQL mode
SELECT a # b FROM t;
This mode reads # as a line comment, which is correct MySQL and what Auto inherits. If the query was written for PostgreSQL, that # was XOR and everything after it on the line has just been deleted.
A # comment above a clause
The same bytes are a comment in two of these modes and an operator in the third, and the difference is visible in where FROM t ends up.
Typed in
SELECT 1 # section FROM t;
Formatted in MYSQL / MARIADB mode
SELECT 1 # section FROM t;
The same text in PostgreSQL mode
SELECT 1 # section FROM t;
Minified in MYSQL / MARIADB mode
SELECT 1 FROM t;
Minified in PostgreSQL mode
SELECT 1 # section FROM t;
Auto and this mode agree: the # run is lifted onto its own line as a comment. Minify then removes it outright, so an annotation an audit trail relies on does not survive minification.
A string literal ending in a backslash
The classic Windows-path case. If a backslash escapes the next character, the first literal runs past its closing quote and fuses with the next one — and the text between the quotes starts being treated as code.
Typed in
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Formatted in MYSQL / MARIADB mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
The same text in PostgreSQL mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
The same text in SQLite mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Minified in MYSQL / MARIADB mode
SELECT 'C:\' AS p, ' a FROM b ' AS q FROM t;
Minified in PostgreSQL mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Minified in SQLite mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
MySQL honours backslash escapes inside string literals, so this mode follows Auto: the trailing backslash escapes the closing quote, the two literals fuse, and the text between them is reflowed as if it were code. Correct for MySQL, destructive for PostgreSQL.
What does not change
MYSQL / MARIADB constructs come through formatting and minifying with the same characters they went in with, in every mode. That is deliberate — the layout pass is engine-agnostic — but read it as "your tokens survive", never as "the tool understands MYSQL / MARIADB". It cannot validate anything, and broken SQL will be prettified into something that looks correct.
- backtick identifiers:
SELECT `order` FROM `t`;
- the two-argument
LIMIT offset, count:SELECT * FROM t LIMIT 10, 20;
GROUP_CONCATwithSEPARATOR:SELECT GROUP_CONCAT(x SEPARATOR ',') FROM t;
ON DUPLICATE KEY UPDATE:INSERT INTO t (a) VALUES (1) ON DUPLICATE KEY UPDATE a = a+1;
One warning that applies in every mode
Minify is not a shrinker of meaning. It collapses the statement onto one line and deletes every comment style — --, # and block — so anything an audit trail or an EXPLAIN annotation relies on is gone rather than compressed.
SELECT 1 FROM t;
Frequently Asked Questions
Is there any difference between Auto and MySQL mode?
Not in output. Auto already guesses the way MySQL does, so on every probe this site runs the two modes produce byte-identical text — selecting MySQL changes nothing about how your query is read. The box still matters for queries Auto guesses about: the ambiguous spellings it resolves are MySQL readings, so a query written for another engine can be quietly reinterpreted while looking untouched.
What happens to my # comments when I minify?
They are deleted, not compressed. Minify removes every comment style — --, # and block — and collapses the statement onto one line. An annotation an audit trail or an approval process depends on does not survive the round trip, so keep the commented source and treat the minified line as a disposable copy.
Are backticks, LIMIT 10, 20 and ON DUPLICATE KEY UPDATE preserved?
Yes — MySQL-specific syntax keeps the same characters it went in with, in formatting and in minifying, in all four modes. Read that as "your tokens survive", never as "the tool understands MySQL": there is no parser behind it, so a query with a missing comma or an unbalanced quote will come out looking tidy and still be wrong.