{{img:hero}}MySQL dashboards can feel like a wall of numbers: QPS, buffer pool, threads, locks, “handler reads”… and somehow you’re expected to know what matters. This guide translates the most common MySQL metrics into plain English and uses a scorecard approach to separate healthy signals from noisy ones.

Think “what story does this number tell?” not “can I memorize every counter?”

Use this when you’re on the web (maybe staring at a hosted dashboard in Chrome) and need a calm way to triage without guessing.

The scorecard method (how to use this article)

For each metric group below, score it like this:

  • Green: normal for your workload; don’t chase it.
  • Yellow: watch trends; check one or two related metrics.
  • Red: user impact likely; investigate now.

Most “mystery incidents” become clearer when you look at one metric plus its nearest neighbors (instead of a single scary spike).

{{img:scorecard}}A useful scorecard is comparative: “now vs baseline” and “this host vs peers,” not “is it high?” in isolation.

Throughput metrics: QPS, TPS, and rows read/written

Plain English: How busy MySQL is, and what kind of work it’s doing.

Common terms you’ll see: Queries per second (QPS), transactions per second (TPS), rows examined, rows returned, rows inserted/updated/deleted.

  • Green: QPS/TPS rises and falls with traffic; latency stays stable.
  • Yellow: QPS is flat but latency rises (work got heavier), or rows examined grows much faster than rows returned (less selective queries).
  • Red: QPS drops while traffic is steady (MySQL can’t keep up), or write rate spikes and everything else slows (IO/locking pressure).

What to check next: p95/p99 query latency, top queries by total time, and “rows examined per row returned” on the worst offenders.

Latency metrics: average vs p95/p99 (and why averages lie)

Plain English: How long users are waiting—and whether only some users are getting hit.

Average latency can look fine while a small percentage of requests are timing out.

  • Green: p95/p99 move roughly with the average (no long tail surprise).
  • Yellow: p95 climbs but average is steady (a subset of queries is degrading).
  • Red: p99 jumps sharply (lock waits, IO stalls, or bursts of expensive queries).

What to check next: slow query log (or performance_schema digest), lock wait time, and whether the problem is read-only, write-only, or both.

{{img:latency-tail}}Long-tail latency usually means “some queries are stuck,” not “everything is uniformly slower.”

Concurrency metrics: threads, connections, and “too many clients”

Plain English: How many things are trying to use MySQL at once, and whether they’re doing work or just waiting.

  • Green: connections fluctuate; active (running) threads are much lower than total connections.
  • Yellow: active threads trend upward over time (pool mis-size, traffic growth, or slower queries).
  • Red: connection errors, max_connections reached, or many threads stuck in the same waiting state.

What to check next: application connection pooling settings, thread states (PROCESSLIST), and whether a small number of slow queries is causing a “queue behind them” effect.

InnoDB buffer pool metrics: hit rate, dirty pages, and what “memory pressure” looks like

Plain English: Whether MySQL is serving reads from memory (fast) or going to disk (slower), and whether it can keep up with flushing writes.

  • Green: buffer pool hit rate is consistently high; disk reads don’t spike during normal load.
  • Yellow: hit rate gradually declines as dataset grows; read IO climbs at peak.
  • Red: sudden drop in hit rate paired with a jump in read latency; dirty pages stay high while checkpoints struggle (write stalls).

What to check next: read IO latency, “buffer pool pages free” trend, and whether a new query pattern is scanning large ranges (missing/ineffective indexes).

Locking and waits: deadlocks, lock waits, and “why writes slow reads”

Plain English: Time spent waiting for other transactions, not doing useful work.

  • Green: occasional deadlocks with automatic retries (common in busy apps) and low lock wait time overall.
  • Yellow: lock waits appear during specific jobs (batch updates, migrations) but clear quickly.
  • Red: sustained lock wait time, rising rollback activity, or many queries blocked behind one long transaction.

What to check next: the longest-running transactions, which tables/indexes are hot, and whether queries are touching rows in a different order (a common deadlock trigger).

{{img:locks}}When lock waits spike, the “fix” is often reducing transaction scope, not adding CPU.

Disk and redo metrics: fsync, log writes, and “IO-bound” reality checks

Plain English: Whether the storage layer is the bottleneck (and which kind of storage work is dominating).

  • Green: stable write latency; redo/log activity matches write load.
  • Yellow: periodic IO saturation during backups, analytics queries, or batch jobs.
  • Red: sustained high write latency, fsync spikes, or checkpoints that fall behind (often shows up as bursts of stalls).

What to check next: IO latency (not just throughput), background flushing behavior, and whether you recently changed durability settings (which can shift the performance/durability tradeoff).

Quick checklist: 10 “plain English” questions to ask when a chart looks scary

  • Did traffic change? Compare QPS/TPS to the same time yesterday/last week.
  • Is it everyone or a tail? Compare average vs p95/p99 latency.
  • Is MySQL busy or blocked? Look at active threads and wait states.
  • Is it reads, writes, or both? Split metrics by read/write where possible.
  • Are we scanning more rows than usual? Rows examined vs rows returned.
  • Are we leaving memory and hitting disk? Buffer pool hit rate + read IO latency.
  • Are locks piling up? Lock wait time + long transactions.
  • Is storage the limiting factor? IO latency (read and write), fsync, checkpoint pressure.
  • Did a deploy change query shape? Top query digests by total time before/after.
  • What’s the baseline? One “bad” number without a baseline is just trivia.

Takeaway: build a small “metric bundle” you trust

If you only remember one thing: don’t chase single metrics. Keep a small bundle—QPS/TPS, p95/p99 latency, active threads, buffer pool behavior, lock waits, and IO latency—and compare it to your normal baseline. Most incidents become obvious when those six move together in a consistent story.