SQL and test data
Make long SQL conditions and joins easier to read
Tools to use
When a long SQL statement appears in a log, first ask what it retrieves. Horizontal scrolling makes parentheses and join conditions easy to miss. Formatting exposes structure and gives you a reading order, but readability does not establish correctness. The tool neither connects to a database nor executes SQL.
Break an invented order query into clauses
Select PostgreSQL and format this example. SELECT, FROM, LEFT JOIN, WHERE and ORDER BY become easier to locate, with uppercase keywords. Read returned fields, starting table, joined table, surviving rows and ordering in that sequence. These are fictional tables; there is no need to run the query.
select o.id,o.total,c.name from orders o left join customers c on c.id=o.customer_id where o.status='paid' and (o.total>=1000 or o.priority=true) order by o.id;Keep the original for comparison. Capitalization and newlines do not repair logic. Table existence, permissions and result counts require database context. Successful formatting is not semantic validation or proof that execution will succeed.
Read the scope of AND and OR
The example requires paid and either total at least 1000 or priority true. Without parentheses, normal precedence permits priority orders regardless of paid status. Formatting exposes grouping but cannot know your business rule. Try fictional rows such as a small paid order, a large unpaid order and an unpaid priority order.
Read JOIN ON separately from WHERE. Requiring a right-side value in WHERE can remove unmatched rows from a LEFT JOIN. The keyword alone does not guarantee every left row survives subsequent filters. Moving a condition can change semantics and deserves a separate query review, not treatment as formatting.
Choosing a dialect is not migrating SQL
Select the input's dialect: PostgreSQL, MySQL or SQLite. Formatting MySQL as PostgreSQL does not translate functions, types, quoting or date behavior into compatible SQL. If syntax is unsupported, inspect the original dialect rather than switching merely to obtain a successful result.
Logs may wrap SQL with timestamps, identifiers and durations. Identify the actual SQL range without deleting newlines or quotes belonging to literals. If parameters are logged separately, inspect their mapping before manually building a seemingly complete interpolated statement.
When the same named argument appears twice
The placeholder converter accepts SQL and argument JSON separately. Two occurrences of :id become $1 twice in PostgreSQL style. Question-mark style requires an argument for each occurrence, so its mapping repeats the value. Copy the argument mapping as well as the SQL; do not keep the old order blindly.
SELECT * FROM users WHERE id = :id OR manager_id = :id
Arguments: {"id":7}
PostgreSQL: id = $1 OR manager_id = $1
Question: id = ? OR manager_id = ? → [7, 7]This converter has limits: it distinguishes ordinary quoted strings and comments from parameters, but is not a complete dialect parser. PostgreSQL also uses ? as an operator, so question-mark input is restricted. Verify complex dialect-specific statements against the database and driver documentation.
Decide what to investigate after reading
Too many rows suggests filters or joins; wrong values suggest parameters or NULL; slowness requires execution plans and data context. Formatting measures neither runtime, index usage nor locks. It provides a readable statement for investigation, not an optimization result.
Share fictional values in place of personal or secret data while preserving the relevant structure. Database execution is a separate authorized step. Read clauses and grouping first, then parameter mapping, so the question is clear before any execution is considered.
Once the SQL is readable, reason about row counts
After formatting the JOIN, ask how many rows on the other side match each order. A supposedly single customer can multiply rows if the join key is not unique. The formatter reads neither schema nor data and cannot validate cardinality. Do not hide unexpected rows with DISTINCT before inspecting the relationship that creates them; formatting makes that investigation easier, not complete.
A WHERE condition on the nullable side of a LEFT JOIN can remove unmatched rows. Moving a condition between ON and WHERE is not cosmetic. Use the clearer structure to reason about which rows survive, with a small fictional dataset and an explicit expected result. The tool does not relocate conditions or execute the query; authorized database verification remains separate.
Readability does not establish performance: indexes, row counts, statistics and plans were not provided. Report formatting separately from a verified optimization preserving results. The latter needs database-specific plans and measurements. Uppercase keywords and newlines are not performance evidence.