# Expected Diagnosis: intermittent-plan-regression-during-cpu-spike

The expected result should converge on the case-specific mechanism below while
keeping conclusions bounded by the collected evidence.

## Expected conclusion

Outer-join reordering in TiDB v6.5.6 used a greedy, non-cost-based path. Whether a ref_id parameter matched a TopN value changed cardinality estimates and could produce a very poor join order, driving excessive TiKV work and CPU. A global binding or disabling tidb_enable_outer_join_reorder is the practical mitigation.

## Required evidence chain

- Compare the good and bad execution plans and show that the regression is parameter-dependent rather than a uniform workload increase.
- Identify greedy outer-join reordering and TopN-sensitive cardinality estimates as the mechanism that selects the bad join order.
- Connect the bad join order to amplified TiKV reads and CPU.
- Recommend a global binding or disabling outer-join reordering, with validation against representative parameter values.