# Expected Diagnosis: repeated-component-restarts-during-maintenance-window

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

## Expected conclusion

A HeidiSQL client repeatedly issued SHOW TABLE STATUS against a very large database. The metadata path enumerated tables and partitions and loaded statistics into memory that was not charged to the originating session, so TiDB could not kill the responsible statement. After each TiDB OOM, the client reconnected through TiProxy and retried on another node, producing repeated cross-node deaths.

## Required evidence chain

- Correlate OOM/restart events across TiDB instances with repeated SHOW TABLE STATUS activity from the client.
- Explain that the metadata/statistics allocation was not fully charged to the originating session, preventing normal statement-level memory enforcement.
- Show how client reconnect and retry through TiProxy propagated the same failure to successive nodes.
- Recommend stopping the client retry loop and avoiding the statement on very large schemas; scaling or restart alone is temporary.