High alert noise from MySQL Performance Schema statement summary despite tuning

Goal: Configure MySQL Performance Schema to provide aggregated statement and error metrics for alerting that signal real problems without generating excessive notifications.

Challenge: Enabling the right combination of setup_consumers and setup_instruments balances alert coverage against runtime overhead and data volume, but the optimal set varies with MySQL version and workload characteristics, leaving the decision unresolved.

Questions: Which Performance Schema consumers should be active to capture statement latency, lock waits and error counts while keeping overhead below an acceptable threshold? How can administrators determine the minimal instrumentation set needed for reliable alerting on a given workload without resorting to trial‑and‑error tuning?