Connection count is easy to chart and easy to misinterpret. A server can support many idle connections but struggle with a smaller number of simultaneously active sessions. MySQL also has per-session memory consumers, so a configuration that appears safe at average concurrency can become risky during a burst of sorts, joins or temporary-table work.
Measure active work, not only open sockets
Compare total connections with running threads, query latency, CPU, memory and connection failures. A high open-connection count may simply reflect application pooling. A high running-thread count paired with CPU or lock waits is more likely to represent pressure. Check for abandoned connections, idle transactions and retry storms that make the count rise after an upstream failure.
Treat per-session settings as concurrency multipliers
Sort, join and temporary-table buffers are not a promise that every session needs the maximum allocation all the time, but they can become significant under concurrent use. Raise a buffer only after identifying a workload that benefits from it and estimating the worst plausible concurrency. A global setting that helps one report can destabilise the server during a busy period.
Practical investigation sequence
- Identify the client, pool or job responsible for the connection change.
- Separate idle sessions from executing and waiting sessions.
- Rank expensive statements and check whether they create temporary tables or large sorts.
- Fix pool limits, leaks or query shape before raising global limits.
Capacity is a combination of memory, CPU, I/O, connection behaviour and workload. Tune one component in the context of the others, then verify that latency improves without moving the bottleneck elsewhere.
Distinguish three different connection problems
A server at its connection limit, a pool that cannot acquire a connection and a database overwhelmed by active work are different failures. Record the exact application error and where the timeout occurred. A pool can exhaust its own small limit while the database has spare capacity; a database can also become overloaded well before reaching max_connections.
SHOW GLOBAL STATUS
WHERE Variable_name IN (
'Threads_connected', 'Threads_running',
'Connections', 'Max_used_connections',
'Aborted_connects'
);
Threads_connected is a current count, while Connections is cumulative connection activity and must be converted to an interval rate. Max_used_connections is a historical high-water mark. Mixing these values as if all were current gauges creates misleading dashboards. Combine them with process-list states and the application's pool acquisition time.
Example: autoscaling multiplies pool capacity
An application grows from four replicas to twenty during a traffic surge. Each replica retains a pool limit of fifty connections, so the potential database demand rises from 200 to 1,000. The database did not change, but the aggregate pool budget did. A deployment that leaves old replicas draining alongside new ones can increase the transient requirement further.
Set a connection budget across all services, workers and administrative needs. Test whether queuing at the application boundary gives better latency than allowing every request to compete inside MySQL. Bounded queues should reject or time out excess work predictably; an unlimited queue merely hides overload until callers lose patience.
Estimate memory under the query mix you actually run
Do not calculate memory as one session buffer multiplied by the total connection count and call that a precise forecast. Buffers are allocated according to operations, and execution plans can use several kinds of workspace. Instead, reproduce the expensive concurrent mix and observe memory demand, temporary work and response time. Keep operating-system and other database memory needs in the estimate.
After changing pool or memory settings, check completed requests, connection creation rate and errors together. If errors fall but the application queue becomes much longer, the user experience may have deteriorated. The acceptance criterion should include successful throughput and the time users wait, not just the disappearance of a database error.
Keep the evidence for the next incident
Mini DBA MySQL monitoring brings query and metric history together with InnoDB and connection diagnostics for investigating recurring incidents. Available evidence depends on the monitored version, permissions and configured collection.
References and further reading