Performance investigation · SQL

Friday night’s slow API is not an automatic index ticket.

Imagine checkout becoming slow during the evening peak. The on-call engineer needs reproducible clues: which query keeps recurring, which table it reaches, and what the plan is doing—not a guessed index added under pressure.

The incident: Checkout latency rises while the error rate stays flat. Rather than assume that “orders are busy,” this path puts local observations, the live orders schema, and the query plan next to one another.

Turn a hunch into reviewable questions

Check whether one query is doing the damage

proxy analyze groups recorded events by fingerprint, duration, errors, and hot tables. It reads local observation data only, which makes it a good first answer to “which query is worth following?”

dbcli proxy analyze --format json --top 10

Then inspect the real table and its plan

If the slow fingerprint points at orders, confirm its live fields before using explain. That separates a poorly shaped query from a change in the data itself.

dbcli schema orders --format json
dbcli explain "@saved-query" --format markdown

Keep index proposals in review

Get missing-index guidance for the confirmed query, then let migration review decide whether it should become DDL.

dbcli guide missing-index-for "@saved-query" --format json
dbcli skill tasks plan migration-review \
  --param "table=<exact table name>" \
  --param "ddl=<captured dry-run DDL>"