# Single Query Diagnosis and Tuning

## Question

Why is the customer-selected SQL or request slow, why was its execution plan
chosen, and which bounded optimization candidates are supported?

## Enter When

Use for a particular SQL, Digest, execution plan or identified request.
Comparing that target across executions, plans, databases or TiDB/TiFlash
engines remains a single-query question. A SQL mentioned only as a suspected
cause of overall latency does not change the incident into this Scenario.
Do not automatically add workload-hotspot merely because this SQL is slow;
that branch requires an independent resource-attribution question or signal.

## First Evidence Question

Ask for target identity, aligned distinct executions and the execution/plan
facts needed to distinguish the delay. Use the supplied SQL, Digest and plan
as target context; missing Digest alone does not prevent bounded discovery.
The Evidence Agent owns text search, exact Provider selectors and acquisition.
A keyword match is a candidate, not exact SQL identity.

Use Slow Query as the primary workload surface for this target. TopSQL is not
a completion gate: a matched request may be absent from TopSQL top-N.
Do not collect an unrelated ranked SQL inventory.

## Diagnosis and Optimization

Apply tidb-query-tuning for plan choice, actual operator work, estimates versus
actual rows, scan amplification, waits, memory/spill and statistics when supplied.
Keep three conclusions separate: why the optimizer chose the plan, what made
this execution slow, and whether a comparable alternative is proven better.

Compare distinct executions of the same target. Similar actual row counts with
markedly different elapsed time justify investigating resource pressure or
waiting; they do not establish that cause without aligned evidence. Equal
processed keys are not equal actual rows. Compare the same operator and plan
scope, and do not count one record returned by overlapping windows twice.

Use the structured plan as the primary plan source; screenshots are
supplementary. Preserve missing or unsupported facts as gaps, never zero.
Give optimization candidates with the supporting evidence, trade-offs and
verification needed. Never execute or promise a production change.

## Strongest Alternative and Stop

Prioritize a target-matched alternative or a shared, aligned resource/wait
boundary. An unrelated slow sample is background evidence. Refine only one
newly discovered load-bearing question; do not request more SQLs just because
the target or plan was unavailable. Stop at a supported bounded explanation
and advice, or the exact identity, field, retention or execution limitation.