# MVCC Scan Amplification

Use this reference when `scan_detail` contains both `total_keys` and
`process_keys`, especially for a simple query whose execution work is much
larger than its logical result.

## Evidence calculation

Calculate:

```text
scan_amplification = total_keys / max(process_keys, 1)
```

Treat the ratio as a diagnostic heuristic, not a product threshold:

- Below `2x`: do not claim scan amplification from this ratio.
- `2x` to below `10x`: note the difference only if other scan evidence supports
  it.
- `10x` to below `100x`: investigate MVCC versions, tombstones, or a logical
  range that scans many non-result keys.
- `100x` or greater: rank MVCC/storage scan amplification highly when the SQL is
  selective or simple and the logical range does not itself explain the work.

Never convert the ratio alone into a confirmed MVCC root cause.

## Distinguish the candidates

Check these in order:

1. **Wide logical range** — the predicate legitimately covers many current
   rows, so large `process_keys` and `actRows` explain the scan.
2. **MVCC/tombstone amplification** — `total_keys` is far larger than
   `process_keys`, especially on frequently updated/deleted keys or index
   columns.
3. **Plan/access-path problem** — the plan scans an unexpected table/index
   range because of statistics, range construction, partition pruning, or an
   unsuitable index.

When available, use RocksDB skipped-key/delete counters, same-digest samples
from a nearby normal window, GC lifetime/safepoint context, and update/delete
patterns. A large ratio that later collapses while SQL and plan shape stay the
same is strong evidence for transient MVCC/tombstone accumulation.

## Required answer shape

State the exact values and ratio first. Then use bounded language:

```text
The plan scanned <total_keys> keys but processed <process_keys>
(<ratio>x amplification). This is most consistent with MVCC/tombstone scan
amplification rather than coprocessor thread count alone. Confirm with a nearby
normal sample and GC/update history; the current evidence does not prove a
single underlying producer of the old versions.
```

Do not recommend increasing coprocessor or unified-read concurrency as the
primary fix when scan amplification explains the work. More threads can move
the queue without removing the amplified scan cost.