# Expected Diagnosis: cpu-spike-during-incident-window

This case should conclude that the CPU spike was primarily driven by a capacity
shift that raised per-node load, not by an abnormal plan cache failure.

The expected answer should make these points explicit:

- The dominant differentiator is that the available TiDB node count dropped
  while total workload stayed broadly similar, so per-node pressure increased.
- The `prepare:exec:close=1:1:1` usage pattern means plan cache hit=0 can be
  expected and should not be treated as the root cause by itself.
- A correct A/B comparison should note that the suspicious plan cache signal is
  effectively unchanged across the problem window and the baseline window.
- Recommendations should focus on capacity or workload distribution first,
  rather than trying to tune plan cache behavior.