Performance Evaluation Page

This page is original PmaControl documentation. It keeps a practical index structure for MySQL optimization work, without copying third-party content or depending on an external product.

Objective

The performance evaluation page aggregates the main signals of a MySQL server into one reading. It is used to prioritize actions, not to replace DBA analysis.

Useful Dimensions

• Configuration: consistency of variables with memory, storage, and workload.
• Queries: weight of slow and frequent queries.
• Schema: indexes, primary keys, volume, and temporary tables.
• Stability: restarts, connection errors, deadlocks, and thread saturation.
• Capacity: CPU, I/O, QPS, connections, and disk-space trends.

Example Grid

Key Point

A global score has value only if it remains explainable. Every point must lead to a metric, a query, or a verifiable configuration.

Define what is being evaluated

Create one dated assessment per server role and representative workload. Record the observation window, data freshness, version, topology, hardware limits and business objective. Include the application and proxy path when evaluating user latency. A writer, reporting replica and standby do not share the same acceptable workload or risk. This guide describes a review method; the tables below are templates, not measured results or an automatically computed PmaControl score.

SELECT NOW() AS observed_at, @@hostname AS hostname,
       VERSION() AS server_version, @@global.read_only AS read_only;
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
  'Connection_errors_max_connections', 'Innodb_log_waits',
  'Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests'
);

Build an evidence-based assessment grid

Mark missing, stale or disabled instrumentation as unknown. A missing metric must not turn green or contribute a fabricated zero. Keep observation, interpretation and proposed action separate. A buffer-pool miss ratio, a historical connection peak or an unused-index list needs workload context before it becomes a finding.

Prioritize by impact, urgency and confidence

• Critical: current outage, imminent storage exhaustion, confirmed unacceptable data-loss or access exposure.
• High: repeated latency/error objective breaches or growing pressure with a confirmed mechanism.
• Planned: measurable cost or risk without current impact; schedule a controlled validation.
• Unknown: insufficient evidence; assign data collection instead of declaring success.

Make before/after results comparable

Keep hardware, data, traffic mix, concurrency and cache state comparable; record any differences and repeat trials. Database counters need deltas and reset checks. Digest averages are not request percentiles. Report gains and regressions together, retain raw evidence and leave unmeasured fields empty or explicitly unknown. Define acceptance and rollback before the test; a throughput increase accompanied by more failures is not automatically an improvement.

Close the loop with a finding record

For every finding, retain the affected server/query, timestamp, evidence link, confidence, business impact, owner, next action, due date, acceptance test and rollback plan. After remediation, attach the measured result and residual limits; recheck during peak traffic and the next full business cycle. Do not close a finding solely because a setting changed or a global score improved.

Continue the investigation

• Collect evidence with health, schema and security checks; validate actions through tuning and parameter review.

Official references

• MySQL Performance Schema