Are this many MySQL database connections considered normal?

[Sophia63]

I’m seeing a huge number of database connections in my MySQL server and I’m wondering if this is expected behavior.

In my Go application, I establish the database connection during controller initialization like this:

connection, error := sql.Open("mysql", "username:password@tcp(server_ip:3306)/database_name")
if error != nil {
    log.Fatal(error)
}

error = connection.Ping()
if error != nil {
    log.Fatal(error)
}

After that, I create prepared statements using connection.Prepare and execute them later in my code. I’m not manually creating additional connections or doing anything unusual - just letting Go manage the connection pool automatically.

However, I’m noticing tons of active connections and aborted connections in MySQL, which is causing performance issues and sometimes crashes.

What could be causing this behavior? For context, my application serves around 2000 concurrent users generating approximately 20 database queries per second. I don’t think that’s excessive but wanted to mention it.

For my prepared statements, I have 2 SELECT queries, 1 UPDATE, and 1 INSERT. The SELECT operations work like this:

error = selectStatement.QueryRow(apiToken).Scan(&userId)
if error != nil {
    response, _ := json.Marshal(ErrorResponse{"Query Failed"})
    w.Write(response)
    return
}

And for INSERT/UPDATE operations:

updateStatement.Exec(x, y, z)

[elizabeths]

Yeah, this connection pooling issue is pretty common when apps don’t configure Go’s database driver defaults properly. I’ve debugged similar production problems before - it’s usually connection lifecycle management, not just pool limits. Sure, prepared statement cleanup and pool sizing matter, but I’d check your error handling first. When database ops fail, Go often leaves connections in a weird state. That’s probably driving those aborted connection counts you’re seeing. Your code has basic error handling but doesn’t seem to handle connection recovery. With 2000 concurrent users hammering your system, even tiny connection leaks add up fast. I’d add connection health checks and make sure your app gracefully handles database reconnects when connections go stale or timeout.

[Laura219]

Also check your MySQL config - max_connections might be too low. I’ve seen apps run fine in dev then crash in production because MySQL defaults to just 151 connections. With 2k users you’ll definitely need to bump that up or tune your connection pool better.

[Isaac_Cosmos]

Your connection pool settings are the problem. With 2000 users hitting your app, Go’s default pool behavior creates way too many connections. I hit the same issue in production until I set SetMaxOpenConns(25) and SetConnMaxLifetime(5 * time.Minute) on my DB connection. Those aborted connections mean queries are timing out or your pool’s churning connections like crazy. Also make sure you’re handling connection errors properly - failed connections pile up fast under load. Twenty queries per second won’t kill MySQL, but without pool limits Go just keeps opening connections until you max out.

[Ryan_Innovative]

Been fighting MySQL connection issues for years - this screams resource leak. You’re probably not closing prepared statements after use. Every connection.Prepare needs a stmt.Close() deferred right after, or they pile up fast. At 20 queries/second, tiny leaks become huge problems.

Check if you’re creating new prepared statements for every request instead of reusing them. That’ll kill your connection pool.

Run SHOW PROCESSLIST during peak traffic and see if connections sit in sleep state too long. Also make sure you’re handling database timeouts and reconnects properly when the network hiccups.

[Claire29]

totally agree! closing your prepared statements is key. if you forget stmt.Close(), you’re gonna see a huge number of connections stacking up. also, double-check those SetMaxOpenConns and SetMaxIdleConns values; defaults can be way too high for your needs.