CONCEPT Cited by 1 source
MySQL threads_running¶
Definition¶
threads_running is a MySQL server status variable reporting
the number of threads currently executing a query. It is
distinct from threads_connected (threads that hold a connection,
possibly idle) and from the number of open transactions (some of
which may be idle between statements).
mysql> SHOW GLOBAL STATUS LIKE 'Threads_running';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_running | 27 |
+-----------------+-------+
It is one of the most frequently-watched MySQL dashboard metrics and one of the most frequently-misinterpreted.
Why operators watch it¶
threads_running tracks actively-executing queries, so a spike
usually means the database is not keeping up: new queries arrive
faster than old queries finish, so the concurrent-count climbs.
Experienced DBAs often describe it as "the first chart I open"
because, at a glance, the shape of the line tells you a problem is
occurring.
Why it has no stable threshold¶
Noach (sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-1) points out that there is no universal acceptable value:
- Early-morning baseline and peak-traffic baseline are different for the same cluster.
- Product evolution shifts the baseline — what was 50 three months ago is 80 today as adoption grew.
- Query mix matters — 50 point-lookups and 50 full-scans produce the same count but very different pressure.
"Pick a number, and you'll soon find it doesn't hold water."
This makes threads_running a poor primary signal for a
throttler that needs a static
threshold comparison on every check.
Why it still carries signal¶
The metric is a symptom of several underlying queue backups:
| Underlying cause | What you see |
|---|---|
| Commit queue stalled (disk flush slow) | Queries pile up waiting on COMMIT — threads_running climbs |
| Row-level locks | Queries pile up waiting on other queries' locks |
| Page-cache thrash | Queries block on disk reads of cold pages |
| Thundering herd | All replicas miss cache simultaneously |
An experienced operator correlates threads_running with other
signals (I/O wait, lock waits, buffer-pool hit rate) to infer
which underlying queue is backing up. The metric is a
dashboarding signal, not an automation signal.
Relationship to a throttler¶
Because threads_running has no stable threshold, using it
directly in a throttler is fragile:
- Static threshold (e.g.
reject if threads_running > 100): over-throttles during low-load periods, under-throttles during peak. - Dynamic threshold (e.g. p99 over last 10 minutes): smoother but hysteresis-prone and still driven by symptoms of underlying queues.
- Better signal: transaction-commit delay (which isolates the disk-flush queue, concepts/transaction-commit-delay) or connection-pool exhaustion (which has a naturally-derived threshold, concepts/connection-pool-exhaustion).
Seen in¶
- sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-1
— canonical wiki framing of
threads_runningas the throttling- signal case study for "useful metric, unstable threshold". Noach uses it as the counter-example that motivates looking at queue-delay metrics instead.
Related¶
- concepts/symptom-vs-cause-metric — why
threads_runningis useful despite not pointing at a cause. - concepts/transaction-commit-delay — the underlying
commit-queue metric the
threads_runningspike is often a symptom of. - concepts/queue-length-vs-wait-time —
threads_runningis queue length, not queue wait time; the latter is often preferred where measurable. - concepts/database-throttler — the use case where its lack of a stable threshold bites.