Incident Guide · MySQL
"Too many connections" — it's rarely the pool size
Your first instinct is to raise max_connections. That treats the symptom. A connection pool doesn't run out because it's too small — it runs out because connections aren't being returned as fast as they're taken.
Check this first
SHOW FULL PROCESSLIST;
Look specifically at how many connections are sitting in Sleep state. That count is the real signal, not the total connection count.
Common causes, ranked by likelihood
1Connections not closed by the application
A connection is opened but never returned to the pool on some code path — most commonly inside an exception handler that skips cleanup. This shows up as a slow, steady climb in Sleep-state connections over time, not a sudden spike.
2Application-side pool size larger than MySQL's actual limit
Check both numbers side by side — a connection pool configured in your application framework can exceed what max_connections was ever set to handle, especially after scaling up app instances without checking the database side.
3A slow query holding a connection open
One expensive, unindexed query blocks a connection for its entire execution time. Check SHOW FULL PROCESSLIST for anything stuck in Sending data for an unusually long duration.
4Pool size genuinely too small
Only likely if Sleep-state connections are low and traffic has actually increased. This is the least common cause — but the first thing most people change.
What not to do
Raising max_connections when the real cause is #1 or #2 just delays the same wall at a higher number — and adds memory pressure on top of it. Fix the leak or the mismatch first.
Paste your process list, get a ranked diagnosis
OperatorMesh reads your actual connection state and recent deploy context, then ranks the likely cause with a confidence score — instead of working through this list by hand.
⚡ Try it free →