Find slow SQL in history and add indexes for your filters

Dashboards and tools usually hammer the same patterns. Pull execution time and SQL from run history, look at the tables involved, and add indexes that match how people actually query, not how you guessed they would.

How it works

Step 1: Mine query runs for slow or frequent SQL

Show my last 25 queries and how long each took. I’m trying to spot the slow ones.

Each run stores execution_time_ms and sql_text so you can sort by what's actually slow.

Step 2: Align with the physical model

Our slow reports filter orders by status and when they were created. Show the structure of the orders table on our commerce database.

Step 3: Create indexes that match common access paths

Speed up those filters: add an index on status and created_at for orders. If the build can happen in the background, use that.

With --async, index creation returns a job. Poll hotdata jobs until it's done before you expect the faster path.

Who uses this

• Platform engineers connecting production query patterns to concrete index changes.
• Analytics owners tuning tables that BI and agents hit hard.
• Teams whose agent-generated SQL volume keeps climbing and needs guardrails.