b2KIT

Database Index Advisor

Analyze SQL queries and suggest optimal database indexes based on WHERE, JOIN, and ORDER BY clauses.

Tested tool guide Tested browser tools Checked August 16, 2026

What Database Index Advisor does and how it behaves

Database Index Advisor inspects a SQL statement for columns involved in WHERE filters, JOIN conditions, and ORDER BY sorting, then turns those access patterns into candidate index recommendations. It supports an initial indexing review when a query exposes likely lookup, matching, or sort keys. The common mistake is treating a recommendation as proof of a speedup. Query text alone does not reveal table size, value distribution, existing indexes, write volume, or the optimizer's chosen plan, all of which can determine whether an index helps.

How the result is produced

1

Clause analysis

The advisor traces column references in the three clause types named by the tool. A WHERE column indicates a possible lookup key, a JOIN column indicates a possible row-matching key, and ORDER BY columns indicate a possible sorting key. The resulting advice is tied to the access pattern expressed by the submitted SQL statement.

2

Candidate interpretation

When a statement uses several relevant columns, evaluate whether the recommendation represents a composite access path rather than a collection of independent indexes. Composite index order is significant because database engines generally use leading index columns to narrow usable paths. Compare every candidate with the table's current indexes so that a seemingly new recommendation does not merely duplicate an existing prefix.

Good uses

  • Reviewing a customer lookup filtered by email and ordered by creation time before adding an index.
  • Inspecting an orders-to-customers join that also filters order status to identify candidate join and filter keys.
  • Rechecking a reporting query after a new WHERE predicate or ORDER BY clause changes its access pattern.

Limits and checks

  • A suggested index is not an execution plan. Confirm it with the target database's plan inspection command and representative data.
  • Functions, casts, expressions, collations, and partial predicates can require engine-specific index features rather than an ordinary column index.
  • Additional indexes consume storage and add maintenance work to INSERT, UPDATE, and DELETE operations, which a single read query does not show.

Common questions

Does a recommendation guarantee that the query will run faster?

No. The optimizer may prefer a sequential scan on a small table or when a predicate matches much of the table. Statistics, caching, index type, and database version also affect the plan. Create the candidate in a safe test environment, refresh statistics if appropriate, and compare the engine's execution plan and timings with representative parameters.

Should I create every index the advisor suggests?

Usually not. First check whether an existing composite index already has a usable leading sequence for the query, or whether a proposed index substantially duplicates another one. Then weigh read improvement against storage and slower INSERT, UPDATE, and DELETE work. Keep only indexes justified by the broader workload, not just by one submitted statement.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools