MySQL ERROR 1040: Too many connections — fix order that works

What's actually happening here

MySQL error 1040 means the server refused a new connection because all available connection slots are taken. The default max_connections is 151 on most builds, and each connection — even one that's just sitting there doing nothing — holds a slot. So you're not out of RAM or CPU; you're out of slots.

This usually hits after a spike in traffic, a misbehaving app that opens connections and never closes them, or a connection pool sized too aggressively. The quickest way to get back online isn't to reboot MySQL — it's to free up slots. Let's walk through the fixes in the order you should try them.

Fix 1: Kill idle connections (30 seconds)

You don't need to change anything to get back up right now. You just need to reclaim slots. Open a new MySQL session — but wait, you might not be able to. If you can't connect at all, MySQL reserves one extra connection for an account with the CONNECTION_ADMIN or SUPER privilege (in MySQL 5.7 it's SUPER, in 8.0+ it's CONNECTION_ADMIN). So log in as root or a user with that privilege.

mysql -u root -p -e "SHOW PROCESSLIST;"

Look for connections in Sleep state — those are idle. The Time column shows how long they've been sleeping. Kill anything that's been sleeping for more than a few minutes:

mysql -u root -p -e "KILL 12345;"   -- replace with actual ID

Or kill all idle connections in one go (be careful — this will kill even valid ones):

mysql -u root -p -e "SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE command = 'Sleep' AND time > 60;"

Pipe that output back into mysql if you're comfortable with that. The reason this works is that killing a connection frees its slot immediately — MySQL doesn't wait for the client to notice. After you kill a handful, you'll be able to connect again.

If you're on MySQL 8.0.14 or later, you can also use KILL CONNECTION which is the same, but explicit. No difference in practice.

Fix 2: Raise max_connections (5 minutes)

Killing idle connections gets you out of the fire, but if the root cause is a legitimate need for more concurrent connections, you have to raise the limit. Before you do, check what you're actually using:

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Max_used_connections';

If Max_used_connections is close to max_connections, then you genuinely hit the ceiling. The fix is to increase max_connections — but don't just double it blindly. Each connection consumes memory for thread stack, sort buffers, and the connection buffer. On a typical server with 8GB RAM, a jump from 151 to 500 is usually safe, but test it.

Edit your MySQL config file (/etc/my.cnf or /etc/mysql/my.cnf depending on your distro) and add:

[mysqld]
max_connections = 500

Then restart MySQL:

sudo systemctl restart mysql

If you can't restart right now, you can set it dynamically without a restart:

SET GLOBAL max_connections = 500;

That takes effect immediately, but it won't survive a restart — so put it in the config file too.

Here's the catch: if your app opens connections and never closes them, raising max_connections just delays the problem. You'll hit the new limit again. So after you raise it, go check your application's connection pool settings. In Java (HikariCP), you usually want maximumPoolSize to be less than max_connections divided by the number of app instances. In PHP, the issue is often that connections aren't being closed — use persistent connections sparingly.

Fix 3: Add a thread pool (15+ minutes)

If you're still hitting 1040 after raising max_connections, the real problem is that your workload creates too many short-lived connections, and the overhead of creating a thread per connection is choking the server. The answer is a thread pool.

MySQL 8.0 doesn't ship with a built-in thread pool in the community edition — that's a feature in MySQL Enterprise. But you have options:

• MariaDB has a thread pool built in — set thread_handling=pool-of-threads.
• Percona Server for MySQL also includes a thread pool. If you're using Percona, add thread_handling=pool-of-threads to your config and restart.
• ProxySQL or HAProxy in front of MySQL can multiplex connections — they accept many client connections and reuse a smaller set of backend connections.

If you're on standard MySQL community edition, your realistic option is a connection pooler like ProxySQL. It's extra infrastructure, but it solves the real issue: your app is opening too many concurrent connections.

For ProxySQL, the basic idea is:

mysql -h 127.0.0.1 -P 6032 -u admin -padmin
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '127.0.0.1', 3306);
INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('appuser', 'apppass', 10);
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL USERS TO DISK;

Then point your app at ProxySQL (port 6033) instead of MySQL directly. ProxySQL will keep a pool of backend connections to MySQL — usually far fewer than your app's total connections.

Why the order matters

The reason you start with killing idle connections is that it's reversible and instant. You don't risk a config change that makes things worse. Raising max_connections is a moderate step — it requires a restart (unless you set it dynamically) and you need to understand your memory budget. The thread pool is the big hammer — it changes how MySQL handles connections entirely, and it's not a trivial addition.

Also note: if you see error 1040 in the MySQL error log, it'll look like:

[ERROR] [MY-010584] [Server] Can't create a new thread (errno 11) ...

That errno 11 means you've hit the OS thread limit, not just MySQL's limit. That's a whole other problem — check ulimit -u and the max_threads kernel parameter. But that's rare. Most of the time, 1040 is just a connection slot shortage.

One last thing: after you apply any fix, watch Max_used_connections over the next few days. If it keeps creeping up to the limit, you need a more permanent solution — either fix your app's connection handling or add the pooler. Don't just keep bumping max_connections until your server runs out of memory. That's how you get a different error: ERROR 1041: Out of memory.