SQL Index Advisor

The advisor parses your SELECT query and identifies columns used in WHERE clauses (equality, range, LIKE), JOIN ON conditions, and ORDER BY clauses. It suggests single-column indexes for individual conditions, composite indexes when multiple columns on the same table appear in WHERE, and notes ORDER BY columns that benefit from indexing.

A composite index covers multiple columns in a defined order. Use it when your WHERE clause filters on multiple columns from the same table — the database can use one composite index instead of scanning separate single-column indexes. The most selective column (smallest cardinality) should typically come first, with range columns last.

Foreign key columns used in JOIN ON conditions cause full table scans if unindexed — the database must scan every row of the joined table to find matches. An index on the foreign key column turns this into an index lookup, reducing JOIN cost from O(n) to O(log n).

Put higher-cardinality columns (more unique values) first in composite indexes. For example, if filtering by country (low cardinality, ~250 values) and user_id (high cardinality, millions of values), the index should be (user_id, country) for queries that filter on user_id, or (country, user_id) for queries filtering on country first.

Every index adds overhead to INSERT, UPDATE, and DELETE operations because the database must update all indexes on write. As a rough guideline, 3–5 indexes per table is a reasonable range for OLTP workloads. Profile actual query performance with EXPLAIN ANALYZE before adding indexes in production.

No. All analysis runs entirely in your browser using JavaScript. Your SQL never leaves your machine.