Cada conexión cuesta memoria, esté trabajando o esperando. Subir el límite en un servidor que ya está en su techo de memoria convierte un error de base de datos en una máquina que hace swap, que es peor.

Mire qué está conectado

SHOW PROCESSLIST;
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
  • Muchas filas en Sleep: conexiones abiertas y nunca cerradas. Un problema de la aplicación, no de la base de datos.
  • Muchas filas ejecutando la MISMA consulta: una consulta lenta que llega más rápido de lo que termina. Arregle la consulta.
  • Filas en Locked que se alargan: una transacción sujetando un bloqueo mientras todo lo demás hace cola detrás.

Conexiones que no se cierran nunca

Un script que abre una conexión en cada vuelta del bucle, o un pool de conexiones persistentes mayor de lo que el servidor permite, agotará el límite por alto que lo ponga.

SHOW VARIABLES LIKE 'wait_timeout';
-- default is often 28800: eight hours of holding a sleeping connection

Bajar wait_timeout a unos minutos recupera las conexiones abandonadas. Es una red bajo una fuga, no una cura.

Cuándo subirlo SÍ es lo correcto

Si todas las conexiones están haciendo trabajo de verdad y al servidor le sobra memoria, el límite es realmente demasiado bajo.

SET GLOBAL max_connections = 300;
-- and in my.cnf so it survives a restart
Calcule primero la memoria por conexión. 300 conexiones a 12 MB cada una son 3,6 GB antes de que la base haya cacheado una sola fila.
Un salto repentino de conexiones a una hora fija es una tarea programada, no tráfico. La lista de procesos durante el pico la nombra en una línea.