# Slow INSERT Write-Path Routing

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "slow-insert-write-path-routing-2026-08-18",
  "problems": [
    {
      "problemId": "slow-insert-routed-away-from-write-mechanism",
      "summary": "TCID-12989 centered on 10-second INSERT transactions after DDL changes, but the analysis prioritized generic Slow Query and schema metadata instead of locating the aligned write-path boundary that could explain the latency.",
      "status": "optimized_verified",
      "applicability": "Slow INSERT, UPSERT, REPLACE, batch-write, or explicit-transaction tickets where schema or key-distribution changes are possible workload triggers and the immediate scheduler, latch, Raft, storage, flow-control, or service mechanism is not yet established.",
      "issueKeys": ["TCID-12989"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/TCID-12989#problem:slow-insert-routed-away-from-write-mechanism"
      ],
      "signalTextIncludesAny": [
        "slow insert",
        "insert duration",
        "AUTO_RANDOM",
        "PARTITION BY KEY",
        "global unique index",
        "write path mechanism missing"
      ],
      "observedThrough": "2026-08-18",
      "effectiveAt": "2026-08-18T10:52:19Z",
      "verifiedAt": "2026-08-18T11:54:00Z",
      "attemptedAction": "Route slow write statements and transactions to write-path-contention as the primary mechanism scenario, keep per-statement latency and workload concentration orthogonal, and require diagnosis to separate supplied DDL trigger hypotheses from the aligned runtime boundary that can explain the observed latency.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/TCID-12989"
    }
  ]
}
-->

- Owner: Scenario Router and write-path-contention scenario contract
- Source: `TCID-12989`
- Implementation status: merged in PR `#970`, deployed, and replay verified
- Effective status: `optimized_verified`

## Bounded problem

The ticket asks why large INSERT transactions became roughly 10 seconds after
changing `bank_transaction` from an `AUTO_INCREMENT` layout to `AUTO_RANDOM`,
a global unique index, and 16 key partitions. Those DDL facts can change key
distribution and material writes, but they do not identify the immediate
runtime boundary. The prior route let generic Slow Query and a fabricated
metadata lookup consume the analysis before the aligned Commit/Prewrite,
scheduler/latch, Raft/storage, and flow-control chain was established.

## Intended change

- Treat a slow write statement or explicit transaction as a write-path symptom.
- Keep `write-path-contention` primary while retaining query latency and
  workload hotspot only as orthogonal questions.
- Use supplied DDL directly and keep it in the trigger chain.
- Require an aligned runtime boundary before attributing the latency to
  `AUTO_RANDOM`, partitioning, or the global index.

## Verification status

Local route and scenario-contract tests are pending. Case-specific replay,
deployment, and Jira internal-comment refresh have not started.

## Unresolved gaps

The frozen replay may still lack enough store-local evidence to confirm one
mechanism. A bounded `human_required` conclusion remains valid when the
available historical window cannot align the write workload with its
Commit/Prewrite, scheduler/latch, and strongest storage alternative.

## Next validation action

Run local route and skill tests, then one branch-local historical read replay.
The replay passes only when it starts from the write-path mechanism, uses the
supplied DDL without a schema lookup, and separates observed mechanism from DDL
trigger hypotheses.