Uso alto de CPU en MySQL: diagnóstico paso a paso

Los síntomas llegan juntos: el sitio web se arrastra, top muestra a mysqld o mariadbd al principio de la lista y a veces la aplicación informa "Too many connections". Ya sea uso alto de CPU en MySQL o MariaDB con CPU alta, la causa rara vez es un servidor demasiado pequeño. Con mucha más frecuencia un puñado de consultas hace mucho más trabajo del que debería, y todo lo demás hace cola detrás. Esta guía recorre el diagnóstico en versiones actuales como MySQL 8.4 y MariaDB 11, desde la primera mirada en vivo hasta una solución duradera.

Paso 1: vea qué hay detrás del uso alto de CPU en MySQL ahora mismo

Conéctese con el cliente de línea de comandos (en MariaDB se llama mariadb) y ejecute SHOW FULL PROCESSLIST. Cada fila es una conexión: cuánto tiempo lleva ejecutándose su instrucción actual, su estado y el texto completo de la consulta. Los patrones saltan a la vista rápidamente:

• Docenas de copias de la misma consulta, cada una ejecutándose durante segundos: una consulta costosa golpeada por el tráfico normal.
• Muchas conexiones en estado Sleep: la aplicación abre conexiones y no las cierra, o su pool es demasiado grande.
• Estados como "Waiting for table metadata lock": un cambio de esquema o una transacción larga está bloqueando a todos los demás.
• Estados de ordenamiento y de tablas temporales en muchas filas: agrupación u ordenamiento sin un índice adecuado.

Dos contadores de estado completan el cuadro. Threads_running muestra cuántas consultas se están ejecutando en este momento, y Max_used_connections el pico desde el último reinicio. Un servidor con unos pocos núcleos de CPU y docenas de hilos en ejecución está sobrecargado por consultas, no por visitantes.

Paso 2: active el slow query log de MySQL

Una instantánea en vivo muestra la crisis; el slow query log de MySQL muestra el patrón. Actívelo fijando slow_query_log en ON con un long_query_time de alrededor de un segundo para empezar, y luego baje el umbral una vez corregidos los peores casos. Ambos se pueden cambiar en tiempo de ejecución y hacer permanentes en el archivo de configuración del servidor. MariaDB usa los mismos nombres de variables y explica las opciones en su descripción general del slow query log.

Deje el registro activo durante unos días de mucha actividad representativos y luego resúmalo. mysqldumpslow, o mariadb-dumpslow en MariaDB, agrupa instrucciones similares, y pt-query-digest de Percona Toolkit ofrece un ranking más detallado. Ordene por tiempo total, no por la consulta individual más lenta: una instrucción que tarda 0.2 segundos pero se ejecuta en cada visita a una página cuesta mucho más que un informe nocturno.

Paso 3: corrija las consultas que importan

Para cada consulta al principio de la lista, ejecute EXPLAIN y lea lo que el optimizador planea hacer. La solución de consultas lentas más habitual es una de estas:

• Un índice ausente o inadecuado. Un recorrido completo de la tabla, que aparece como type ALL, sobre una tabla grande donde un índice compuesto en las columnas filtradas y ordenadas encontraría las filas directamente.
• Una función sobre una columna indexada, como envolver una columna de marca de tiempo en una función de fecha dentro de la cláusula WHERE, lo que impide usar el índice. Reescribir la condición como un rango lo resuelve.
• Comodines al inicio en las búsquedas con LIKE, que ningún índice ordinario puede ayudar. La verdadera solución es un índice de texto completo o un servicio de búsqueda.
• La misma consulta pequeña repetida cientos de veces por página, típica de plugins y bucles de la aplicación, que se resuelve mejor con caché en la aplicación.

Pruebe primero los cambios de índices en una copia de la base de datos. Cada índice acelera algunas lecturas, pero añade trabajo a cada inserción y actualización, y crear un índice en una tabla muy grande puede ralentizarla mientras se construye.

Por qué "Too many connections" suele ser un síntoma

El error significa que todas las conexiones permitidas están en uso. El valor predeterminado de max_connections tanto en MySQL como en MariaDB es 151, y subirlo resulta tentador. Sin embargo, cada conexión necesita memoria, y más consultas simultáneas en los mismos núcleos de CPU solo hacen que cada una sea más lenta. En su lugar, busque la causa de las demasiadas conexiones:

• Consultas lentas que mantienen las conexiones abiertas, lo que nos devuelve al Paso 3.
• Más workers de PHP-FPM o hilos de la aplicación de los que la base de datos puede atender a la vez. El nivel web debe dimensionarse para que su pico quepa dentro de max_connections, dejando margen para la administración.
• Conexiones inactivas abiertas durante horas por conexiones persistentes o un pool sobredimensionado, controladas por wait_timeout y por los ajustes de pool de la aplicación.

Revisiones de configuración y ajuste de rendimiento de MariaDB

Cuando las consultas estén bajo control, revise los ajustes que determinan cuánto debe trabajar el servidor de base de datos. El buffer pool de InnoDB debe contener los datos que se usan con regularidad, para que las lecturas salgan de la memoria y no del disco. Las tablas temporales que se vuelcan a disco aparecen en el contador Created_tmp_disk_tables. Estas revisiones son el núcleo de una revisión del rendimiento de MySQL y MariaDB. La caché de consultas no es una solución: MySQL 8 la eliminó, y MariaDB la incluye desactivada porque se convierte en un punto de contención en servidores con mucha actividad. Para el ajuste de rendimiento de MariaDB en servidores con muchas conexiones cortas, vale la pena mirar el thread pool. Y si todavía usa MySQL 8.0, tenga en cuenta que Oracle terminó su soporte en abril de 2026; 8.4 es la versión de soporte a largo plazo a la que pasan la mayoría de los servidores con 8.0, y una actualización es un buen momento para volver a revisar los planes de ejecución de las consultas.

Preguntas frecuentes: uso alto de CPU en MySQL

¿El uso alto de CPU siempre es un problema de la base de datos?

No. Si mysqld o mariadbd no está cerca del principio de la lista de procesos, revise PHP, el servidor web o una tarea de copia de seguridad. La base de datos es la probable culpable cuando su proceso domina y la lista de procesos muestra consultas acumulándose.

¿Debo reiniciar MySQL cuando la CPU está al máximo?

Un reinicio despeja la cola por un momento, pero las mismas consultas vuelven con el tráfico, y además un reinicio vacía el buffer pool, así que el servidor va más lento hasta que se calienta de nuevo. Guarde primero la salida de SHOW FULL PROCESSLIST para no perder la evidencia.

¿Puedo terminar una consulta de larga duración de forma segura?

KILL QUERY con el ID de conexión de la lista de procesos detiene la instrucción y mantiene abierta la conexión, mientras que KILL termina la conexión. Detener una escritura grande puede tardar un poco porque sus cambios se revierten, y no corrige la causa, así que anote la consulta antes de terminarla.

Si una base de datos en Los Ángeles o en cualquier otro lugar sigue funcionando al límite, nuestro servicio de optimización de bases de datos MySQL y MariaDB revisa el slow query log, los índices y la configuración, y la mayor parte del tiempo transcurrido se dedica a reunir un registro de consultas lentas durante unos días de mucha actividad y no a los cambios en sí. Cuando el servidor web es la otra mitad del problema, consulte nuestro servicio de optimización de servidores web Apache. Contáctenos con la versión de su base de datos y una descripción de cuándo ocurren las lentitudes.