# Query Execution

This file is retained for persisted `query-execution` compatibility only. New
routes must select `cluster-query-latency`, `workload-hotspot`, or both instead of
combining their objectives here.

## Question

Which digest or plan operation explains the symptom, and is the mechanism scan
amplification, executor wait, spill, coprocessor/RocksDB work, or resource use?

## Enter When

Use for slow SQL, high CPU tied to a digest, plan/regression evidence, excessive
scanned rows, Cop wait, RocksDB fields, spill, or executor bottleneck.

## First Batch

1. Start from supplied plan, SQL Digest, trace, or Slow Query artifact; never
   request a Digest already present in `input/customer-evidence.json`.
2. Align execution rate/latency and affected, processed, or scanned rows with
   the incident.
3. Inspect only the direct plan/operator or storage/executor mechanism and one
   competing resource/wait boundary.

When discovery is still required, first select exactly one affected or
highest-impact instance from the entities aligned to the direct result sample
for the queried component, then request only its Top 10 Digest summary. Do not
select it from a wider-window CPU maximum or dashboard legend. Use at most 10
compact Slow Query or Statements decision rows on the same TiDB instance.
Treat the provider compact report as the reasoning source; do not load a
complete raw TopSQL, plan, statement, or Slow Query artifact into context.

## Decision

TopSQL rank, statement count, an `ANALYZE` entry, or high CPU alone does not
prove causality. Missing provider fields are unavailable, not zero. Preserve
CPU units: `rate(process_cpu_seconds_total[...])` is cores and a value
multiplied by 100 is a one-core percentage scale.

For the CPU-hotspot objective, apply the common contract's bounded CPU causal
admission: aligned node-local TopSQL contribution plus corroborating process
CPU change or recovery can confirm the workload cause. Lower-level operator
details are auxiliary, not a stopping prerequisite. This does not establish a
latency mechanism or turn a partial contribution into the entire CPU increase.

When a causal SQL or plan is established, use the bundled
`tidb-query-tuning` skill for detailed tuning while keeping this scenario's
incident alignment.

## Strongest Alternative And Stop

Compare with one normal execution/window and the closest wait/resource
alternative. Stop when the bounded CPU workload cause is established, one
operator path explains the latency result, or the exact load-bearing missing
plan/field is named.