SQL Formatter, Linter & Analyzer

SQL (Structured Query Language) is the standard language for defining, querying and manipulating relational data. Because SQL is whitespace-insensitive, the same query can be written as one cramped line or as a neatly indented block — and teams almost never agree on a single style by hand. A SQL formatter (also called a beautifier or pretty-printer) parses your query into tokens and re-prints it with consistent keyword casing, indentation and line breaks, so the clause structure — SELECT, FROM, JOIN, WHERE, GROUP BY — is obvious at a glance.

This tool is built around a hand-written SQL tokenizer that understands string literals, quoted identifiers ("col", `col`, [col]), comments, numbers, operators, bind parameters and dialect quirks. On top of that tokenizer sit a formatter, a minifier, a validator, a linting engine, a quality scorer, a compatibility checker, an execution-plan analyzer and a documentation generator. Everything runs client-side in JavaScript, so you can safely paste production queries, internal table names and sensitive logic — nothing is transmitted, logged or stored on a server.

Almost all day-to-day SQL falls into a handful of statement types. Understanding their shape makes every query you read or write far clearer.

• SELECT — reads rows. The canonical order is SELECT columns, FROM a table, optional JOINs, a WHERE filter, GROUP BY for aggregation, a HAVING filter on groups, ORDER BY to sort and LIMIT to cap rows.
• INSERT — adds rows: INSERT INTO t (a, b) VALUES (1, 2). Always list columns explicitly so a schema change never silently shifts your values.
• UPDATE — modifies existing rows: UPDATE t SET a = 1 WHERE id = 5. The WHERE clause is mandatory in practice — without it, every row changes.
• DELETE — removes rows: DELETE FROM t WHERE id = 5. Same warning as UPDATE.
• DDL (CREATE, ALTER, DROP, TRUNCATE) — defines and changes the schema itself: tables, columns, indexes, views, procedures and triggers.

A logical detail that trips up beginners: SQL does not execute in written order. The database evaluates FROM and JOIN first, then WHERE, then GROUP BY and HAVING, then SELECT(which is why a column alias defined in SELECT usually can't be used in WHERE), then ORDER BY, and finally LIMIT. Keeping that evaluation order in mind explains many "column does not exist" errors and helps you reason about performance.

Joins combine rows from multiple tables. An INNER JOIN keeps only matching pairs; a LEFT JOIN keeps every left-hand row and fills unmatched right-hand columns with NULL(perfect for "find rows with no match" via WHERE right.id IS NULL); FULL JOIN keeps both sides. Prefer explicit JOIN … ON over comma joins — the latter hide the join condition in the WHERE clause and make accidental cross joins easy. The linter in this tool flags comma joins for you.

Most slow queries share a small set of root causes. Learning to spot them — and letting the linter and execution- plan analyzer in this tool point them out — will resolve the majority of database performance problems.

• Full table scans. When the database reads every row because no usable index exists for your filter, latency grows linearly with table size. In a plan this appears as Seq Scan (PostgreSQL) or type: ALL (MySQL). Fix it by indexing the filtered/joined columns.
• Non-sargable predicates. Wrapping an indexed column in a function — WHERE YEAR(created_at) = 2024 — disables the index. Rewrite as a range: created_at >= '2024-01-01' AND created_at < '2025-01-01'.
• SELECT *. Fetching every column inflates I/O and network transfer and prevents covering-index optimizations. List only the columns you need.
• Leading-wildcard LIKE. LIKE '%term'can't use a normal B-tree index; use a trailing wildcard, full-text search, or a trigram index.
• N+1 queries. Running one query per row in application code instead of a single set-based join is the most common ORM performance bug. Batch with a join or IN list.
• Implicit type casts. Comparing a string column to a number (or vice-versa) can force a cast that defeats the index. Match types exactly.

The golden rule of SQL tuning is to measure, don't guess. Capture an EXPLAIN ANALYZE for the real query and paste it into the Execution Plan tab here: it will identify the costliest operations, flag sequential scans and nested loops over large inputs, and recommend specific indexes.

An indexis an auxiliary data structure — almost always a B-tree — that lets the database find rows by a column's value without scanning the whole table, much like the index at the back of a book. Indexes dramatically speed up reads but add cost to writes (every INSERT/UPDATE/DELETE must also maintain them) and consume storage, so they are a deliberate trade-off rather than a free win.

• Single-column indexes accelerate equality and range filters on one column.
• Composite indexes cover multiple columns and follow the left-prefix rule: an index on (a, b, c) helps queries filtering on a, on a, b, or on a, b, c — but not one filtering on b alone. Order the columns most-selective-first, and put equality columns before range columns.
• Covering indexesinclude every column a query needs, so the database answers it from the index alone (an "index-only scan") without touching the table.
• Unique indexes enforce uniqueness and double as a fast lookup. Primary keys are backed by one automatically.
• Partial / filtered indexes index only rows matching a condition (e.g. WHERE deleted_at IS NULL), keeping the index small and hot.
• Functional / expression indexes index the result of an expression, restoring index use for otherwise non-sargable predicates like LOWER(email).

Avoid over-indexing: redundant indexes slow writes and confuse the planner. Build large indexes online where possible (PostgreSQL CREATE INDEX CONCURRENTLY) to avoid locking writes, and periodically review unused indexes. The execution-plan analyzer here recommends missing indexes based on the scans it detects.

Beyond indexing, the structure of a query itself matters. These rewrites consistently pay off:

• Filter early and narrow. Apply the most selective WHEREconditions first and avoid pulling columns or rows you'll discard later.
• Prefer EXISTS / JOIN over IN (subquery) for correlated checks, and prefer NOT EXISTS or an anti-join over NOT IN, which returns no rows if the set contains a NULL.
• Replace deep nesting with CTEs. WITH clauses turn a tangle of subqueries into named, sequential steps that read top-to-bottom and are easier to optimize and debug. The complexity score in this tool rewards flattening nesting with CTEs.
• Use window functions (ROW_NUMBER(), RANK(), SUM() OVER (…)) for running totals, top-N-per-group and period comparisons instead of self-joins.
• Paginate with keyset pagination (WHERE id > :last_id ORDER BY id LIMIT 20) instead of large OFFSET values, which still scan and discard all skipped rows.
• Keep statistics fresh. Run ANALYZE so the planner has accurate row estimates; a bad estimate is the hidden cause behind many surprising plans.

Optimization is iterative: change one thing, re-run EXPLAIN ANALYZE, compare. Paste each plan into the Execution Plan tab to keep the feedback loop tight.

SQL is a frequent attack surface and an easy place to cause irreversible damage. The linter in this tool surfaces the most important risks, but the underlying principles are worth internalizing.

• Always parameterize. Never build SQL by concatenating user input. Use bind parameters (?, :name, $1) so the database treats input strictly as data — this is the single most effective defense against SQL injection. The linter flags concatenation that looks like hand-built SQL.
• Guard destructive writes. A DELETE or UPDATE without a WHERE clause touches every row. The linter raises this as an error.
• Apply least privilege. Grant only the specific privileges a role needs; avoid GRANT ALL. Application accounts rarely need DDL or superuser rights.
• Protect against irreversible DDL. DROP and TRUNCATE are unrecoverable without a backup — gate them behind reviewed migrations.
• Minimize data exposure. Select only the columns you need, mask or omit PII in logs, and avoid returning secrets in error messages.

Good schema design prevents whole classes of bugs and performance problems. A few durable principles:

• Normalize first, denormalize deliberately. Aim for third normal form (3NF) — every non-key column depends on the key, the whole key, and nothing but the key — then denormalize only where measured read performance demands it.
• Choose keys carefully. Every table should have a primary key. Surrogate keys (auto-increment / UUID) decouple identity from changeable business data. Enforce real relationships with foreign keys.
• Pick the right types. Use the narrowest correct type — DATE/TIMESTAMP for time, exact DECIMAL for money (never FLOAT), and constrained VARCHAR(n) where appropriate.
• Name consistently. Pick one convention — snake_case is the SQL norm — for tables and columns, and stick to it. The linter flags mixed identifier casing.
• Add constraints. NOT NULL, UNIQUE, CHECKand foreign keys move data-integrity rules into the database where they can't be bypassed.

Paste your CREATE TABLE statements into the Documentation tab to instantly generate a column/key/ relationship reference you can export to Markdown or HTML.

A SQL linter performs static analysis on the query text, flagging issues without executing anything. This tool runs rules across six categories — naming, formatting, anti-patterns, performance, security and maintainability— each with a severity (error, warning, info) and, where safe, a one-click fix. "Fix all" re-formats and applies every safe correction at once.

The quality score distils all of this into a single 0–100 health score, plus five sub-scores: Security, Performance, Maintainability, Readability and Complexity. The overall figure is a weighted blend (security and performance carry the most weight) and is fully deterministic — the same query always scores the same — so you can track improvement as you refactor, or wire the report into code review. Export the full report as Markdown, HTML, JSON or CSV from the Quality tab.

SQL is a standard, but every database extends it. A query written for MySQL often won't run on SQL Server or Oracle without changes. The Compatibility tab scans your query for dialect-specific features and shows, for nine databases, whether each is supported, partially supported or unsupported:

• Row limiting: LIMIT (MySQL/Postgres/SQLite) vs TOP (SQL Server) vs ROWNUM/FETCH FIRST (Oracle).
• Auto-increment: AUTO_INCREMENT (MySQL) vs SERIAL (Postgres) vs IDENTITY (SQL Server) vs sequences (Oracle).
• Identifier quoting: backticks (MySQL/BigQuery) vs double quotes (standard) vs brackets (SQL Server).
• Upserts: ON DUPLICATE KEY UPDATE (MySQL) vs ON CONFLICT (Postgres/ SQLite) vs MERGE (SQL Server/Oracle).
• Functions: NVL (Oracle) vs ISNULL (SQL Server) vs IFNULL (MySQL) vs the standard COALESCE; GROUP_CONCAT vs STRING_AGG vs LISTAGG.

Common questions worth being able to answer crisply:

• What's the difference between WHERE and HAVING? WHERE filters rows before grouping; HAVING filters groups after aggregation.
• INNER vs LEFT JOIN? INNER keeps only matching rows; LEFT keeps all left rows, NULL-filling unmatched right columns.
• How do you find duplicate rows? GROUP BY the columns and add HAVING COUNT(*) > 1.
• Get the second-highest salary? Use a window function: ROW_NUMBER() OVER (ORDER BY salary DESC) and filter for rank 2, or a correlated subquery.
• What is a CTE and when is it better than a subquery? A named, top-level temporary result set (WITH) that improves readability, can be referenced multiple times, and supports recursion.
• What makes a query non-sargable? Applying a function or implicit cast to an indexed column in the WHERE clause, which prevents index use.
• UNION vs UNION ALL? UNION removes duplicates (an extra sort/hash); UNION ALL keeps them and is faster.
• How do transactions guarantee correctness? Via ACID — Atomicity, Consistency, Isolation, Durability.

1. Paste or upload your SQL (or click "Load sample"). Everything stays in your browser.
2. Format & validate with one click — pick your dialect, keyword case and indentation.
3. Lint to surface security, performance and style issues, then apply one-click fixes.
4. Score the query for an at-a-glance 0–100 health rating with actionable notes.
5. Check compatibility across MySQL, PostgreSQL, SQL Server, Oracle, SQLite, MariaDB, Snowflake, BigQuery and Redshift.
6. Analyze the execution plan by pasting EXPLAIN output to find bottlenecks and missing indexes.
7. Document & export schema docs and reports to Markdown, HTML, JSON or CSV.

Pair the SQL tool with the rest of the Omnitool developer suite: