SQL Index Advisor

The advisor uses regex-based pattern matching to extract tables and aliases from the FROM/JOIN clauses, columns from WHERE conditions, JOIN ON predicates, and ORDER BY expressions. It then classifies each column reference and generates CREATE INDEX recommendations. It handles common SQL patterns but is not a full SQL parser — very complex subqueries or CTEs may not be fully analysed.

Use a composite index when your query consistently filters on multiple columns from the same table together (e.g., WHERE status = 'active' AND created_at > ?). Put equality columns first, range columns last. A single-column index is better when a column is frequently queried alone across many different queries.

Selectivity measures how many distinct values a column has relative to total rows. High selectivity (e.g., user_id, email) means an index narrows down results to very few rows — excellent candidates for indexing. Low selectivity (e.g., status with only 3 values, boolean flags) means an index still returns a large fraction of the table — often not worth the overhead. The advisor flags low-selectivity columns with a warning.

Hash indexes are only useful for equality lookups (col = ?). They cannot handle range queries (col > ?, col BETWEEN), sorting, or partial matches. In PostgreSQL, Hash indexes are rarely worth it since B-tree handles equality just as fast in practice. MySQL's InnoDB does not support explicit Hash indexes on disk — only in the adaptive hash index buffer. Use Hash only when you have a very specific equality-only access pattern on a memory-based table.

No. Every index you add slows down INSERT, UPDATE, and DELETE operations because the index must be maintained on every write. Indexes also consume disk space and memory. Only add indexes that serve actual query patterns observed in production. Use EXPLAIN ANALYZE to verify an index is being used before adding it permanently.

No. All analysis runs entirely in your browser using JavaScript. Your query text is never sent to any server.