ORIGINAL COMPANY-CONTEXT PRACTICE
Diagnose a query slowdown after the data distribution changes
Original practice scenario: A hypothetical enterprise query is unchanged but becomes much slower after a few customers grow substantially. Explain a diagnosis that separates plan choice from logical correctness.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Compare representative parameters, execution evidence and data distribution before changing the query. An unchanged SQL string can encounter a different workload or cardinality pattern.
Work through it
- Capture the intended result grain, actual row counts at major operators and timing for both typical and unusually large tenants, protecting sensitive values in diagnostics.
- Inspect join keys, filter selectivity, statistics and indexes, checking for correlated columns or skew that make independence estimates misleading.
- Test a targeted change against equivalent results and multiple parameter sizes, measuring memory, spill behavior and concurrency effects rather than one fast isolated run.
Tradeoffs to discuss
- A plan optimized for a dominant tenant may hurt small tenants; partitioning or separate strategies add operational complexity.
Common pitfalls
- Do not add an index without examining write cost and whether the query can use it.
- A faster query that changes join or NULL semantics is not a valid performance fix.