SQL Query Analyzer
Detect SQL anti-patterns like SELECT without WHERE, cartesian products, and index-killing functions — with complexity scoring
Paste one or more SQL statements. The analyzer detects anti-patterns and estimates complexity automatically.
What is the SQL Query Analyzer?
The SQL Query Analyzer detects performance issues and anti-patterns in your SQL queries. It identifies common mistakes that cause slow queries — full table scans, cartesian products, index-killing function calls, over-fetching with SELECT *, and deeply nested subqueries — and provides actionable recommendations for each issue found. It also estimates overall query complexity on a 1-10 scale.
How to Use
- Paste one or more SQL statements into the input area
- The analysis runs automatically as you type
- Review detected issues with severity levels and recommendations
- Check the complexity score to gauge query maintainability
- Use the Export button to download a full report
Use Cases
- Code review — Quickly spot SQL anti-patterns before they reach production
- Performance debugging — Identify why a query is slow without running EXPLAIN
- Query auditing — Scan a batch of queries from migration files or stored procedures
- Learning — Understand why certain SQL patterns hurt performance
- Pre-deployment checks — Catch missing WHERE clauses before they lock tables
Example: Detecting Anti-Patterns
Given this query with multiple issues:
SELECT *
FROM users u, orders o
WHERE UPPER(u.email) = 'TEST@EXAMPLE.COM'The analyzer detects three issues: SELECT * (over-fetching), a cartesian product between users and orders (no join condition between the two tables), and UPPER() applied to the email column in WHERE (prevents index usage). Each issue includes severity, explanation, and a concrete recommendation.
Detected Anti-Patterns
- SELECT without WHERE (high severity) — Full table scans that read every row
- Cartesian products (high severity) — Multiple tables without join conditions
- JOIN without ON/USING (high severity) — Explicit joins missing conditions
- Subqueries (medium-high severity) — Nested SELECTs that may not optimize well
- Functions on columns in WHERE (medium severity) — Prevents index usage
- SELECT * (low severity) — Fetches unnecessary data, harder to maintain
Complexity Scoring
Complexity is scored on a 1-10 scale based on query structure: number of JOINs, subqueries, set operations (UNION/INTERSECT), GROUP BY, HAVING, window functions, CTEs, DISTINCT, and ORDER BY. The score maps to labels: simple (1-2), moderate (2-4), complex (4-7), and very-complex (7-10).
Privacy and Security
All analysis happens entirely in your browser using JavaScript. Your SQL queries — which may contain table names, column names, and business logic — never leave your device. No data is stored, logged, or transmitted to any server. For large inputs (over 50KB), processing automatically offloads to a Web Worker to keep the page responsive.
Frequently Asked Questions
What SQL anti-patterns does the SQL Query Analyzer detect?
The analyzer detects six common anti-patterns: SELECT without WHERE (full table scans), joins without conditions (cartesian products), subqueries that may impact performance, functions applied to columns in WHERE clauses (which prevent index usage), SELECT * (over-fetching columns), and provides an overall complexity estimation based on joins, subqueries, window functions, CTEs, and set operations.
How is query complexity estimated?
Complexity is scored on a 1-10 scale considering multiple factors: number of JOINs (0.8 per join, max 3), subqueries (1.2 each, max 3), set operations like UNION/INTERSECT (0.7 each), GROUP BY and HAVING (0.5 each), window functions (0.6 each), CTEs, DISTINCT, and ORDER BY clauses. The score maps to labels: simple (1-2), moderate (2-4), complex (4-7), and very-complex (7-10).
Why is SELECT without WHERE flagged as high severity?
A SELECT without WHERE clause reads every row in the table (full table scan). On tables with millions of rows, this can lock resources, consume excessive memory and I/O, and make other queries wait. Adding a WHERE clause allows the database engine to use indexes and read only the necessary rows.
Why are functions on columns in WHERE clauses a problem?
When you wrap a column in a function (e.g., WHERE UPPER(name) = 'JOHN'), the database cannot use an index on that column because it needs to compute the function value for every row first. Instead, normalize the comparison value (WHERE name = 'JOHN') or create a functional index. This is one of the most common causes of slow queries that developers overlook.
Is my SQL sent to any server for analysis?
No. All analysis runs entirely in your browser using JavaScript. Your SQL queries — which may contain table names, column names, and business logic — never leave your device. No data is stored, logged, or transmitted to any server.
Does the analyzer support all SQL dialects?
The analyzer works with standard SQL syntax and detects patterns common across MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, and SQLite. It focuses on universal anti-patterns rather than dialect-specific features. The detection is based on SQL structure analysis, not a full parser for any specific dialect.
Can I paste multiple SQL statements at once?
Yes. The analyzer splits your input by semicolons (respecting string literals and comments) and analyzes each statement independently. The report includes the total statement count and issues found across all statements. Line numbers in the findings help you locate each issue.
What is the difference between SQL Query Analyzer and SQL Index Helper?
The SQL Query Analyzer detects anti-patterns and estimates complexity — it tells you what problems exist in your queries. The SQL Index Helper focuses specifically on suggesting which indexes to create based on your WHERE, JOIN, ORDER BY, and GROUP BY clauses. Use both together: first identify issues with the analyzer, then optimize with index suggestions.