Database & Backend
SQL Query Optimizer & Index Advisor
Analyze SQL queries for sargability pitfalls, missing composite indexes, and slow offsets. Generate production CREATE INDEX DDL and optimized rewrites for PostgreSQL, MySQL, and SQLite.
Slow Query Presets:
Target Engine:
Engine Tuning Note: POSTGRES
PostgreSQL supports CONCURRENTLY for zero-lock index creation, as well as B-Tree, BRIN, and GIN trigram indexes.
60
Query Health & Sargability Score
Performance bottlenecks detected
Up to 50x Faster
Wildcard SELECT * Invalidation
mediumQuery selects all columns (*), which prevents index-only covering scans and forces high disk and buffer cache read overhead.
Fix: Replace SELECT * with explicit columns needed by the consumer.
Non-Sargable Expression: YEAR(created_at)
highWrapping column 'created_at' in function YEAR() invalidates standard B-Tree index lookups and causes a full table scan for every row.
Fix: Rewrite to a range condition (e.g. created_at >= '2026-01-01' AND created_at < '2027-01-01') or create a functional index.
Rewritten Sargable SQL Query
-- Query using non-sargable function on indexed column & leading wildcard SELECT id, order_number, total_amount, created_at FROM orders WHERE created_at >= '2026-01-01 00:00:00' AND created_at < '2027-01-01 00:00:00' AND LOWER(customer_email) LIKE '%@gmail.com' ORDER BY order_total DESC;
Advertisement
How to use
- 1Paste your SQL SELECT query into the SQL editor, or click one of the preset buttons above the editor.
- 2Select your target database dialect (PostgreSQL, MySQL, or SQLite).
- 3Review the Health Score and detected performance bottlenecks (Non-Sargable functions, missing composite indexes, wildcard LIKE, large offset scans).
- 4Click "Copy Index DDL" to copy the suggested CREATE INDEX statement, or copy the rewritten optimized query for your codebase.
Frequently asked questions
What is a non-sargable SQL query?
SARGable stands for "Search Argument Able". A query predicate is non-sargable when a function, expression, or implicit conversion wraps an indexed column (e.g. YEAR(created_at) = 2026 or LOWER(email) = "x"). The database engine cannot perform a fast B-tree index seek and must resort to a full table or index scan across every row.
How does the composite index advisor determine column order?
It follows the standard Rule of Equality First: Equality columns (e.g. tenant_id = "abc", status = "active") come first in the index tuple, followed by ORDER BY / Range columns (e.g. created_at DESC). This allows the database engine to locate the exact slice in a single index seek without needing an in-memory filesort.
Is my SQL query or schema sent to any external server?
No. The query analysis, AST tokenization, sargability rule engine, and DDL generation execute 100% in your browser using client-side JavaScript. Your internal table names, column structures, and sensitive query filters never leave your machine.
Which database dialects are supported?
The optimizer generates tailored DDL index statements and query rewrites for PostgreSQL (including CONCURRENTLY and partial/functional indexes), MySQL / MariaDB, and SQLite (covering indexes and PRAGMA analysis).
Why is large OFFSET bad for pagination?
OFFSET 10000 LIMIT 20 requires the database engine to scan and discard 10,000 full rows before returning 20. Keyset pagination (cursor-based pagination using WHERE id > last_seen_id) allows O(1) index seeks regardless of page depth.
The Senior Full-Stack Production Kit (2026)
Checklists, Docker recipes, and SSR error fixes in one dense PDF.