PHP and MySQL
Fix MySQL “Too many connections” at the cause
Diagnose connection leaks, slow queries, pool sizing and requests running together before raising max_connections.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
The error can mean leaked connections, an oversized application pool, slow queries holding sessions, traffic spikes or an unavailable database copy. Raising max_connections uses more server memory and may postpone failure while making overload worse.
What this means in plain English
MySQL allows only a limited number of connections because every connection uses resources. The error can come from leaked connections, slow work holding them open, oversized connection pools or a sudden traffic spike.
Raising the limit may use more memory and let an overloaded database accept even more work. First count the maximum connections requested by every application copy, inspect active and sleeping sessions and find transactions or queries that stay open too long.
Why are connections accumulating?
| Demand | Application copies × maximum pool size |
|---|---|
| Duration | How long active and idle sessions remain |
| Database capacity | Memory and work for every connection running together |
A simple example
Ten app instances each allow a pool of 50 connections, so they can ask for 500 even though MySQL allows 200. Normal use needs far less. Reducing each pool, closing leaked sessions and making excess requests wait safely fixes the cause without giving MySQL an unsafe limit.
What to do, step by step
1. Compare every pool maximum with the database limit.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on demand: application copies × maximum pool size. Write the result down so you can compare it later.
2. Inspect active versus sleeping sessions.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Trace slow queries and unfinished transactions.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Limit pools and make excess requests wait safely before raising limits.
Finish by checking the result against database capacity: memory and work for every connection running together. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Check what happens when an application instance stops. A pool should close cleanly rather than leaving work or long transactions behind.
Common mistakes and how to avoid them
Doubling max_connections first.
This gives a misleading or unsafe result because it leaves out demand. A better approach is to compare every pool maximum with the database limit, then check the result before making the change permanent.
Giving every process a large private pool.
This gives a misleading or unsafe result because it leaves out duration. A better approach is to inspect active versus sleeping sessions, then check the result before making the change permanent.
Ignoring sleeping connections and transaction age.
This gives a misleading or unsafe result because it leaves out database capacity. A better approach is to trace slow queries and unfinished transactions, then check the result before making the change permanent.
Words explained
- MySQL
- A database that stores structured information such as accounts, orders, settings and website content.
Quick checklist
- Compare every pool maximum with the database limit.
- Inspect active versus sleeping sessions.
- Trace slow queries and unfinished transactions.
- Limit pools and make excess requests wait safely before raising limits.
Common questions
What is the simple answer?
The error can mean leaked connections, an oversized application pool, slow queries holding sessions, traffic spikes or an unavailable database copy. Raising max_connections uses more server memory and may postpone failure while making overload worse.
What should I check first?
Start with demand: application copies × maximum pool size. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Compare every pool maximum with the database limit. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Doubling max_connections first. Avoiding that one mistake makes the rest of the comparison much more trustworthy.