Configurar my.cnf para optimizar MySQL en WordPress

Si tu WordPress va lento, te da errores de conexión a la base de datos o el servidor se cae justo cuando llega tráfico, hay muchas probabilidades de que el problema esté en el archivo my.cnf. La configuración que trae MySQL por defecto casi nunca se ajusta a lo que un sitio real necesita. Aquí va una explicación de dónde encontrar ese fichero, qué parámetros importan de verdad y qué valores aplicar según la RAM de tu servidor.

¿Qué es el archivo my.cnf y dónde se encuentra en Linux?

my.cnf es el fichero de configuración principal de MySQL (y de MariaDB, su fork más habitual). Ahí se definen cosas críticas: el tamaño de la caché de consultas, el límite de conexiones simultáneas, la memoria que reciben los buffers de InnoDB. Y como WordPress guarda todo en MySQL —entradas, opciones, usuarios, relaciones— cualquier mejora aquí se nota directamente en los tiempos de carga.

La ubicación depende de la distribución y de cómo instalaste el servidor. Las rutas más habituales en Linux:

• Debian y Ubuntu: /etc/mysql/my.cnf (que suele incluir el directorio /etc/mysql/mysql.conf.d/)
• CentOS, RHEL y Rocky Linux: /etc/my.cnf
• Instalaciones de MariaDB: /etc/mysql/mariadb.cnf o /etc/my.cnf.d/server.cnf

¿No tienes claro qué archivo está leyendo MySQL realmente? Este comando te lo dice:

mysql –help | grep -A 1 «Default options»

Muestra el orden de prioridad en que el servidor busca sus ficheros de configuración. El último de la lista que exista en tu sistema es el que manda. Ojo con esto: un parámetro duplicado en dos archivos puede provocar comportamientos raros que te costarán horas diagnosticar. Y antes de tocar nada, copia de seguridad. Siempre. cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak.

Cómo configurar my.cnf: parámetros esenciales para WordPress

Hay un grupo de directivas, dentro de la sección [mysqld], que marca la diferencia entre un servidor ágil y uno saturado. Empieza por estas:

• innodb_buffer_pool_size: el parámetro más influyente de todos. Define la memoria dedicada a cachear datos e índices de InnoDB. En WordPress todas las consultas pasan por InnoDB, así que un valor demasiado bajo obliga al sistema a leer desde disco constantemente. Mal asunto.
• max_connections: el número máximo de conexiones simultáneas. Un valor bajo hace que WordPress escupa «Error establishing a database connection» en los picos de tráfico; uno excesivo te agota la RAM.
• innodb_log_file_size: un tamaño mayor mejora las escrituras. Útil si publicas mucho o montas una tienda con WooCommerce.
• query_cache_size: solo sirve en MySQL 5.7 o en MariaDB antiguas. En MySQL 8.0 eliminaron la caché de consultas, así que ni la incluyas si usas esa versión.
• tmp_table_size y max_heap_table_size: amplían el tamaño máximo de tablas temporales en memoria, lo que reduce operaciones en disco en las consultas más complejas.
• skip-name-resolve: desactiva la resolución DNS de los clientes y baja la latencia en cada conexión.

Cada cambio exige reiniciar el servicio para aplicarse: systemctl restart mysql (o mariadb, según tu instalación). Mi recomendación: aplica los ajustes de uno en uno y mide el rendimiento entre medias. Si lo cambias todo de golpe, nunca sabrás qué hizo el bien y qué hizo el daño.

Valores recomendados de my.cnf según la memoria de tu servidor

No existe una configuración universal, ojalá la hubiera. Los valores correctos dependen de la RAM total disponible y de si el servidor aloja solo la base de datos o también todo el stack de WordPress (Nginx o Apache, PHP-FPM, etc.). Estas cifras son orientativas, para el escenario típico de un VPS con WordPress instalado en el mismo equipo:

Servidor con 2 GB de RAM

• innodb_buffer_pool_size: 512M
• max_connections: 75
• innodb_log_file_size: 128M
• tmp_table_size / max_heap_table_size: 32M

Servidor con 4 GB de RAM

• innodb_buffer_pool_size: 1G o 1,5G
• max_connections: 100
• innodb_log_file_size: 256M
• tmp_table_size / max_heap_table_size: 64M

Servidor con 8 GB de RAM

• innodb_buffer_pool_size: 4G a 5G
• max_connections: 200
• innodb_log_file_size: 512M
• tmp_table_size / max_heap_table_size: 128M

Como regla general: si MySQL comparte servidor con WordPress, dedica entre el 50 y el 60 por ciento de la RAM al innodb_buffer_pool_size. Si el servidor es exclusivamente de base de datos, puedes subir hasta el 70 por ciento. Después de aplicar los cambios, comprueba el estado del buffer con SHOW GLOBAL STATUS LIKE ‘InnoDB_buffer_pool_read%’; y verifica que el ratio de lecturas desde memoria supere el 99 por ciento.

¿Prefieres no experimentar con la configuración en producción? ¿O necesitas afinar valores concretos para un proyecto con mucho tráfico? En RedServicio (redservicio.net) puedes encontrar ayuda profesional para optimizar tu servidor MySQL y resolver cualquier incidencia técnica.

Cómo aplicar los cambios y reiniciar MySQL sin romper tu sitio

Ya tienes my.cnf configurado. Bien. Ahora toca aplicar los cambios, y aquí es donde muchos admins se llevan sustos. Antes de reiniciar el servicio, valida siempre la sintaxis del archivo con mysqld –validate-config (a partir de MySQL 8.0.16) o, si tienes una versión anterior, revisa los logs justo después del arranque. Un solo carácter erróneo puede impedir que MySQL arranque. Y con él, tu WordPress entero caído.

El proceso, paso a paso:

1. Haz una copia del archivo original: cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak.
2. Aplica los cambios con tu editor de siempre y guarda.
3. Programa el reinicio en una ventana de bajo tráfico. Madrugada, idealmente.
4. Reinicia con systemctl restart mysql o systemctl restart mariadb, según lo que uses en tu distribución.
5. Comprueba que el servicio está activo con systemctl status mysql y verifica que WordPress carga bien.

¿Cambios mayores? Por ejemplo, tocar innodb_buffer_pool_size en un servidor con tráfico real. Entonces conviene aplicar el valor en caliente con SET GLOBAL antes de tocar el archivo: SET GLOBAL innodb_buffer_pool_size = 2147483648; funciona sin reiniciar en MySQL 5.7 o superior. Si el resultado es estable, lo consolidas en my.cnf. Si no, no has tocado nada de la configuración permanente. Cero riesgo.

Errores comunes al editar my.cnf y cómo solucionarlos

Aquí es fácil cometer deslices que acaban en fallos graves. Los he visto todos, y casi siempre se repiten los mismos:

• MySQL no arranca tras el reinicio. Revisa el log de errores, normalmente en /var/log/mysql/error.log. Casi siempre hay un valor mal escrito o una directiva duplicada detrás. Restaura el backup con cp my.cnf.bak my.cnf y vuelve a intentarlo con calma.
• Duplicar directivas en varios archivos. MySQL lee varios ficheros de configuración en orden (my.cnf global, my.cnf del directorio de datos, configuración del usuario). La última directiva leída gana. Así que un valor duplicado puede sobrescribir el tuyo en silencio, sin ningún aviso. Con mysqld –help –verbose ves exactamente qué archivos se cargan.
• Asignar más memoria de la disponible. Si sumas innodb_buffer_pool_size, key_buffer_size y los caches por conexión y el total supera la RAM, el sistema empezará a usar swap o, peor, el proceso será eliminado por el OOM killer. Calcula el consumo total antes de fijar valores. Siempre.
• Confundir variables globales con variables por sesión. Directivas como max_allowed_packet bajo [mysqld] afectan al servidor; si las pones bajo
  , solo al cliente. Coloca cada directiva en su sección correcta, porque MySQL no te avisará del error.
• Unidades incorrectas. Escribir 512M cuando querías 512G, u olvidar la unidad del todo, hace que el valor se interprete en bytes. Verifica con SHOW VARIABLES LIKE ‘innodb_buffer_pool_size’; que el valor aplicado es el que esperabas.

Una práctica que funciona bien: cambia un solo bloque de directivas cada vez y monitoriza el rendimiento durante unos días antes del siguiente ajuste. Así sabrás qué cambio produce cada efecto. Si tocas cinco cosas a la vez, no lo sabrás nunca.

Conclusión: optimiza MySQL y acelera tu WordPress

Pocas mejoras tienen tanto impacto en el rendimiento de un sitio WordPress como una my.cnf bien configurada, sobre todo cuando la base de datos crece y las consultas empiezan a ralentizar la carga de páginas. Valores bien dimensionados en innodb_buffer_pool_size, max_connections, tmp_table_size y los caches de InnoDB marcan la diferencia entre un servidor que responde en milisegundos y uno que se colapsa con el primer pico de tráfico.

Los pilares del proceso, en resumen: parte de una configuración conservadora, mide con herramientas como MySQLTuner antes y después de cada cambio, aplica las modificaciones en horas de bajo tráfico y guarda copias de seguridad de cada versión del archivo. Y ten paciencia. La optimización de MySQL es un trabajo iterativo, no una tarea de una sola sesión.

Si tras aplicar estos ajustes tu WordPress sigue yendo lento, o prefieres que un especialista revise la configuración con garantías, en RedServicio (redservicio.net) encontrarás ayuda profesional para optimizar tu servidor MySQL, diagnosticar problemas de rendimiento y mantener tu sitio funcionando al máximo.