Why MySQL Throws ‘Too Many Connections’ and How to Fix It

What Is “Too Many Connections”?

The MySQL server reports ERROR 1040 (HY000): Too many connections when the number of simultaneous client connections exceeds the max_connections limit. Each MySQL user also has a max_user_connections limit, which triggers ERROR 1203 (42000) when exceeded. DBAs can monitor the Connection_errors_max_connections status variable to detect when the server refuses connections.

Key Parameters

max_connections : maximum permitted number of simultaneous client connections.

max_user_connections : maximum simultaneous connections allowed for a single MySQL user.

Connection_errors_max_connections : number of connections refused because max_connections was reached.

When Does the Error Occur?

Two main scenarios trigger the error:

Slow queries – either genuinely slow queries or “pseudo‑slow” queries that appear fast but are delayed by other factors.

Sleep (idle) connections – connections that remain open without executing queries, usually because the application fails to release them promptly.

Practical Case 1: Sleep Connections Causing TMC

Cause : Application code does not close connections, leading to a large number of idle SLEEP threads that eventually exhaust max_connections.

Solution Steps :

Identify the issue early; otherwise downstream services cannot reach the database.

Kill idle connections. Manual killing is impractical at scale, so automate the process.

Configure wait_timeout so MySQL automatically closes idle sessions.

Work with the business team to fix the root cause in the application code.

Consider enabling the thread_pool plugin (not available in the community edition) for better connection handling.

Practical Case 2: Slow Queries Causing TMC

Real slow query : A genuinely long‑running query that can be optimized once identified.

Pseudo‑slow query : Queries that appear fast but are delayed by resource contention, making the bottleneck hard to locate.

Symptoms :

“Too many connections” error.

Very high Threads_running count.

Most queries show no obvious slowness.

Overall query latency spikes.

Server I/O pressure remains modest.

Important InnoDB Parameters

innodb_thread_concurrency : Number of threads allowed to enter the InnoDB engine simultaneously; excess threads queue.

innodb_thread_sleep_delay : Sleep time for threads waiting to enter InnoDB.

innodb_adaptive_max_sleep_delay : Adaptive maximum sleep time.

innodb_concurrency_tickets : Ticket count that lets a thread bypass the queue temporarily.

Test Reproduction

To simulate the issue, set the concurrency to a low value:

set global innodb_thread_concurrency = 1; -- simulate low concurrency

Run three queries that start within one second of each other. With innodb_thread_concurrency limited, subsequent queries wait, mimicking a “pseudo‑slow” situation.

Observations

Analysis of trx_started and NOW() shows that InnoDB’s internal adaptive scheduling does not guarantee fair distribution; some queries wait even if they are fast.

Conclusion

1. When innodb_thread_concurrency is saturated, even fast queries become blocked, creating the illusion of a slow query.

2. MySQL’s internal scheduling uses adaptive algorithms that are not strictly FIFO; deeper source‑code study is required for full understanding.

3. Once the root cause is identified, the remedy is to reduce concurrent threads, use monitoring platforms (e.g., Omega) to pinpoint high‑traffic queries and connections, and collaborate with developers to eliminate idle connections or optimize problematic queries.