database-performancelisted

# Database Performance ## Purpose Turn “the database is slow” into a bounded symptom, a short set of competing mechanisms, and a handoff to the skill that owns the decision. Database incidents cross layers: one endpoint can combine an ORM statement explosion, pool waiting, a stale plan, lock contention, and engine maintenance debt. Leave this skill once the owner is known. ## Triage contract Start with the symptom, time window and known environment; collect only the signals needed to choose the next owner. The packet below is a menu, not a prerequisite to handoff. For greenfield selection, route from requirements and workload evidence without inventing existing engine metrics. ```text business symptom, SLO impact, and exact time window: engine, exact version/edition/service tier, topology, and recent changes: operation/query/job and representative parameters/data distribution: offered/completed rate, concurrency, errors/timeouts, and transaction p50/p99: application statement count, pool acquire/usage/pending, and connection count: database CPU, I/O, waits/locks, active sessions, log/WAL/redo, and replica lag: plan identity plus estimated/actual rows, loops, reads/buffers, spills, and cache state: affected cohort and comparable healthy control: evidence gaps, collection risk, rollback window, and success measure: ``` Do not infer an engine mechanism from an application symptom. Align clocks and workload before correlating layers. Identify metric boundaries: pool usage