Mi base de datos ralentiza mi sitio. ¿Debería tener su propio servidor?

Tu tienda carga bien a primera hora de la mañana y se arrastra a la hora de comer. El escritorio de WordPress tarda unos segundos en abrir un producto, y una prueba de velocidad te da una puntuación decente con una nota vaga sobre el tiempo de respuesta del servidor. Alguien en un foro dice que el problema es la base de datos, y otra persona asegura que un servidor más grande lo arreglará.

La propia guía de bases de datos de WordPress de DreamHost señala que las herramientas de velocidad online no llegan a tu base de datos, así que un sitio puede puntuar bien y aun así ejecutar consultas lentas. Necesitas una prueba que mire dentro de la página mientras se genera. Eso es lo que hace Query Monitor.

Iremos por orden: averiguar si MySQL es la parte lenta, arreglar lo que puedas en el servidor que ya tienes y, después, decidir si merece la pena un servidor MySQL privado y qué cambia cuando se mueven tus datos.

Comprueba que la lentitud viene de la base de datos

Puedes hacer todas las comprobaciones siguientes desde tu panel y WordPress sin permisos de administrador en el servidor MySQL, y ninguna cambia tu sitio más allá de instalar un plugin.

1. Averigua en qué servidor MySQL estás y dónde está

   Abre la página MySQL Databases de tu panel y fíjate en el nombre del servidor que aparece junto a cada base de datos. La guía de DreamHost sobre registros de bases de datos explica los nombres: uno que empieza por iad1 es un servidor MySQL compartido, sql seguido de un número es un servidor MySQL privado y ds es un servidor dedicado. Si el tuyo ya empieza por sql, estás en un servidor privado y las señales de compra que verás más abajo no te afectan. Después abre la página Data Centers del panel. Tus servidores web y MySQL deberían estar en el mismo centro de datos para reducir el retardo de red, y el soporte puede trasladarlos si no lo están.

2. Instala Query Monitor y compara dos cifras

   Query Monitor es un plugin gratuito que enumera todas las consultas a la base de datos de una página y las agrupa por plugin, tema o núcleo de WordPress. Inicia sesión como administrador y abre una página que notes lenta. El menú del plugin en la barra de administración muestra el tiempo de generación de la página y el tiempo total de las consultas SQL, ambos en segundos. Compáralos. Si el tiempo de consultas es una parte pequeña del tiempo de generación, lo que frena la página es otra cosa, como las llamadas HTTP o el renderizado de bloques.

3. Encuentra el plugin y las consultas que consumen el tiempo

   Abre el panel Queries by Component. Está ordenado por tiempo total, así que el plugin o tema que más tiempo pasa en la base de datos aparece arriba, y el autor del plugin lo señala como el punto de partida cuando un sitio va lento. Query Monitor marca una consulta como lenta cuando supera los 0,05 segundos. También señala las consultas duplicadas, que suelen indicar que el código ejecuta una consulta dentro de un bucle cuando podría hacerla una sola vez y guardar el resultado en caché.

4. Carga la misma página en una hora tranquila y en una de mucho tráfico

   Query Monitor no guarda historial. Apunta las cifras. Carga la página lenta en un momento tranquilo y otra vez en tu hora de más tráfico, y compara el tiempo total de consultas y los tiempos de esas mismas consultas lentas. El artículo de DreamHost sobre cómo mejorar el rendimiento de la base de datos incluye las ralentizaciones en los picos de tráfico entre las señales de que la base de datos es el cuello de botella, y recomienda revisar también el uso del servidor en esos picos.

5. Consulta tu gráfico de uso en esas mismas horas

   En el alojamiento web, la página Servers & Usage representa la CPU, la RAM y el almacenamiento como Low, Medium o High durante el último día, la última semana o las dos últimas semanas. La guía de uso del Centro de ayuda explica que la CPU y la RAM del servidor web se comparten entre cuentas, pero los gráficos muestran solo el uso de tu cuenta. Una lectura High apunta a tu propio PHP y a tus plugins. Una normal te dice que tu cuenta no es la que más consume, pero no puede decirte lo ocupado que está el resto del servidor.

Ahora relaciona lo que has visto con una causa probable:

Lo que MySQL compartido no te deja ver

En MySQL compartido no puedes ver los registros del servidor, incluidos los de consultas lentas, y la guía de DreamHost sobre registros de bases de datos indica que el soporte tampoco puede obtenerlos por ti. Además, tu usuario de MySQL no tiene el privilegio PROCESS, así que la lista de procesos solo muestra tus propias consultas, y no puede ejecutar SET GLOBAL para cambiar la configuración del servidor.

Así que el registro de consultas lentas del que habla el manual de MySQL queda fuera de tu alcance aquí: está desactivado por defecto y solo alguien con permisos de administrador en el servidor puede activarlo. Su límite por defecto es de 10 segundos. La misma guía del Centro de ayuda dice que el soporte de DreamHost puede obtener los registros de un servidor MySQL privado si lo solicitas. En un servidor dedicado, tienes acceso directo a los archivos de configuración de MySQL.

Primero, arréglalo donde está

Todo esto funciona en el plan que ya tienes, antes de pagar nada.

Revisa las consultas lentas con EXPLAIN. Copia una consulta lenta de Query Monitor. Pon EXPLAIN delante y ejecútala en phpMyAdmin. La documentación de la sentencia EXPLAIN de MySQL explica cómo muestra el plan que usará MySQL, incluidos los índices que lee, y EXPLAIN ANALYZE ejecuta la consulta e informa del tiempo real. El MySQL compartido de DreamHost concede el privilegio INDEX, así que puedes añadir un índice cuando el plan muestre que MySQL recorre una tabla entera. Anota cualquier índice que añadas a una tabla de WordPress o WooCommerce para comprobar que sigue ahí después de las actualizaciones.

EXPLAIN SELECT option_name FROM wp_options
WHERE autoload = 'yes' OR autoload = 'on';

Limpia las tablas propias de WordPress. Los pasos de DreamHost para limpiar la base de datos de WordPress se ejecutan por SSH con WP-CLI. Eliminan los datos transitorios (transients), optimizan las tablas, recortan las revisiones de entradas y limpian las tablas postmeta y commentmeta. Antes de nada, comprueba el tamaño de autoload, porque WordPress carga esas opciones en cada petición; por debajo de unos 600 KB es adecuado para la mayoría de servidores. Estos comandos proceden de ese artículo:

wp transient delete --all
wp db optimize
wp db query "SELECT SUM(LENGTH(option_value)/1048576) as 'Autoload(MB)' FROM $(wp config get table_prefix)options WHERE autoload='yes' or autoload='on';"

Las tablas con mucha sobrecarga ralentizan las consultas y pueden hacer que el servidor web agote el tiempo de espera mientras aguarda una respuesta. La opción Optimize table de phpMyAdmin elimina esa sobrecarga, como explica la guía de DreamHost sobre lentitud.

Activa la caché. La propia documentación de rendimiento de WordPress considera la caché la forma más rápida de mejorar el rendimiento. Un plugin de caché de páginas sirve las entradas y páginas como archivos estáticos, así que la mayoría de visitas nunca llegan a MySQL. Después, añade una caché de objetos.

En el hosting compartido, el Centro de ayuda de DreamHost documenta el plugin Docket Cache como caché de objetos persistente basada en archivos, y OPcache, que este necesita, ya está activado. Si prefieres no gestionar la caché en absoluto, el hosting de WordPress con caché integrada de DreamHost se encarga de ello en el servidor.

Los ajustes a nivel de servidor, como la memoria de InnoDB, son otra tarea, que tratamos en nuestro artículo sobre cómo optimizar MySQL en un VPS.

Señales de que la base de datos necesita su propio servidor

DreamHost describe MySQL compartido como adecuado para bases de datos optimizadas y un rendimiento web estándar, y MySQL VPS como pensado para clientes que necesitan una respuesta más rápida de la base de datos o a los que MySQL compartido se les ha quedado pequeño. La página de MySQL VPS también menciona el límite de compartir en sus preguntas frecuentes: «Un servidor compartido puede provocar cuellos de botella de rendimiento cuando recibe un tráfico inusualmente alto.»

Las consultas lentas por sí solas no significan que MySQL compartido sea el sitio equivocado, así que plantéate un servidor privado solo cuando hayas aplicado las correcciones anteriores y estas señales sigan apareciendo:

• Las mismas consultas van más lentas en tu hora punta. Tus notas de Query Monitor en horas tranquilas y en horas punta muestran que las mismas consultas tardan claramente más cuando hay mucho tráfico, incluso después de la limpieza y la caché.
• Los errores de conexión vuelven una y otra vez después de confirmar el nombre de host y de que el soporte haya revisado el servidor. Un MySQL VPS da a tus bases de datos recursos que no comparten con otros usuarios. DreamHost no publica los límites de conexiones de ninguno de los dos tipos de servidor, así que no podemos darte una cifra.
• Tu aplicación necesita disparadores o rutinas almacenadas. Según el Centro de ayuda de DreamHost, no puedes crear disparadores nuevos en MySQL compartido y las rutinas almacenadas no están disponibles allí, mientras que un MySQL VPS admite ambos.
• Necesitas los registros de MySQL para depurar. Según el Centro de ayuda de DreamHost, el soporte puede obtenerlos de un servidor MySQL privado.

Si no te encaja ninguna, quédate donde estás. Una respuesta de Stack Overflow de 2009 defiende quedarse:

La respuesta más votada del mismo hilo, con 188 votos, defiende lo contrario por motivos de escalabilidad y rendimiento. Usa tus propias cifras de hora punta para decidir.

Qué cambia cuando trasladas la base de datos

Si te preocupa que una base de datos remota añada un salto de red, tu sitio ya lo tiene. La introducción a MySQL de DreamHost indica dónde se ejecuta cada tipo de servidor MySQL:

Por eso el Centro de ayuda de DreamHost pide a los clientes que nunca usen localhost como host de la base de datos. Añadir un MySQL VPS solo cambia dónde está la base de datos, y tu sitio sigue accediendo a ella a través de la red. Las historias de los foros sobre bases de datos remotas vienen de configuraciones distintas. En un hilo de Server Fault, un sitio en EE. UU. usaba una base de datos en Asia y respondía muy despacio hasta que la base de datos pasó a un servidor local. Ese retraso lo causaba la distancia, y por eso la comprobación del centro de datos va primero en los pasos anteriores.

La migración en sí se hace desde el panel:

1. Haz una copia de seguridad de cada base de datos
   Primero exporta una copia de cada base de datos.
2. Añade un MySQL VPS desde el panel

   Si ya tienes un VPS en tu cuenta, usa Add Service+ en la página Servers & Usage. Si no, abre la página MySQL Databases y haz clic en Turn on a MySQL VPS!. Los pasos de DreamHost para añadir un MySQL VPS cubren ambas opciones. El aprovisionamiento puede tardar unas horas.

3. Elige una noche tranquila para la migración

   Según el Centro de ayuda, DreamHost traslada todas las bases de datos de tu cuenta al nuevo servidor a medianoche, hora del Pacífico, y el panel lo muestra como una fusión. No dice si tu sitio deja de funcionar durante la migración ni cuánto tarda. Añade el servidor un día en que la medianoche del Pacífico sea una hora tranquila para tus visitantes y, si necesitas una respuesta segura, pregunta antes al soporte.

4. Busca bases de datos rezagadas

   Algunas bases de datos pueden quedar repartidas entre el antiguo servidor compartido y el nuevo. El botón Move my databases! de la página MySQL Databases las vuelve a reunir en un solo sitio.

5. Comprueba que el hostname coincide y vuelve a probar

   Abre la página MySQL Databases y compara el nombre de host que muestra para cada base de datos con DB_HOST en tu archivo de configuración. Si no coinciden, cambia DB_HOST para que coincida con el panel. Un nombre de host recién añadido puede tardar hasta 4 horas en empezar a funcionar, porque los nombres de host de las bases de datos son nombres DNS. Después carga tus páginas lentas en las mismas horas tranquilas y de mucho tráfico y compara los tiempos con tus notas.

Después de la migración, algunas cosas funcionan de otra manera:

• Sigues sin tener acceso root ni SSH. MySQL VPS es administrado, así que DreamHost se encarga del mantenimiento, los parches de seguridad y las actualizaciones del sistema operativo, y la configuración de MySQL la sigue fijando DreamHost. Si necesitas los archivos de configuración, o tu aplicación mueve grandes cantidades de datos hacia y desde MySQL, DreamHost te recomienda un servidor dedicado, donde MySQL se ejecuta en la misma máquina.
• La RAM puede ampliarse más adelante. Puedes aumentar la RAM desde el panel en cualquier momento y, según el Centro de ayuda, recibes un crédito prorrateado por el plan anterior.
• Puedes ver si tus datos caben en memoria. Ejecuta SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; y calcula 1 menos Innodb_buffer_pool_reads dividido entre Innodb_buffer_pool_read_requests. En un servidor que solo ejecuta tus bases de datos, ese resultado es la proporción de lecturas servidas desde memoria, la cifra que aparece en la tabla de dimensionamiento de abajo. En nuestro MySQL de prueba, un usuario con permisos sobre una sola base de datos podía leer estos contadores, pero no SHOW ENGINE INNODB STATUS.
• Volver atrás tiene un límite de tamaño. Si no tienes un servidor dedicado, cada base de datos del MySQL VPS debe ocupar menos de 3 GB para poder eliminar el servidor desde el panel. Después eliges un servidor al que transferirlas, y DreamHost traslada tus datos al servidor de bases de datos compartido en un plazo de 24 horas.

Qué opción te conviene

Elige la opción que encaje con lo que han mostrado tus comprobaciones.

Si optas por MySQL VPS, empieza por VPS business. La página de DreamHost lo presenta como Pensado para pequeñas empresas, y la lista de planes del panel de DreamHost le asigna 1 GB de RAM y 20 GB de almacenamiento. VPS basic es el escalón inferior. La página describe VPS basic como Para sitios web nuevos y pequeños, lo que encaja con un sitio pequeño cuyo motivo principal para migrar son los disparadores, las rutinas o los registros. VPS basic tiene 500 MB de RAM según la lista de planes de DreamHost. En nuestra prueba, MySQL con su configuración por defecto se detuvo al llegar a un límite de 512 MB bajo carga, incluso con una base de datos pequeña. DreamHost configura MySQL en cada plan y no publica la configuración de VPS basic, así que pregunta al soporte para qué sirve antes de trasladar allí una base de datos con mucho tráfico.

Antes de elegir, comprueba cuánto ocupan tus bases de datos. La guía de DreamHost para optimizar una base de datos incluye esta consulta para averiguarlo. Conéctate a la base de datos por SSH y ejecútala para ver los datos y los índices de cada base de datos en MB:

SELECT table_schema "database", sum(data_length + index_length)/1024/1024 "size in MB" FROM information_schema.TABLES GROUP BY table_schema;

Si el total supera con creces la RAM del plan, MySQL no puede mantenerlo todo en memoria, así que empieza por un plan superior.

Cuántos datos cupieron en 1 GB en nuestra VM de prueba

Pusimos a prueba esa regla antes de fiarnos de ella. En una VM de prueba, le dimos a MySQL 8.4 un límite estricto de memoria equivalente a cada plan de MySQL VPS, con su caché en aproximadamente la mitad, y ejecutamos una carga constante similar a la de un sitio web sobre tres tamaños de base de datos. La tabla muestra cuántas lecturas respondió MySQL desde memoria y cuánto tardó el 5 % de transacciones más lentas. Cada transacción es un lote de lecturas y escrituras, parecido a una visita a una página.

Una base de datos que ocupaba menos de la mitad de la RAM del plan se mantuvo rápida. Cuando los datos superaron la RAM, las transacciones más lentas se ralentizaron: 18,6 ms para la base de datos de 1,8 GB con 1 GB, frente a 8,7 ms en el plan siguiente. Con 4,6 GB en 1 GB, MySQL no pudo seguir el ritmo de la carga en absoluto. Un límite de 512 MB, cercano a los 500 MB de VPS basic, se quedó corto para MySQL con su configuración predeterminada: usaba unos 470 MB antes de ejecutar ninguna consulta, y todas las ejecuciones se detuvieron al llegar al límite.

Esta es nuestra configuración de prueba, no la de DreamHost. DreamHost configura MySQL en cada plan y no publica el tamaño de su caché, y en un MySQL VPS no puedes cambiar la configuración del servidor MySQL. Toma la tabla como una orientación sobre cuántos datos admite con holgura cada tamaño de memoria. La prueba completa, con todos los tamaños de caché que probamos, está en nuestra guía sobre cuánta RAM necesita MySQL.

No podemos decirte cuántos visitantes admite cada plan, porque eso depende más de tus consultas que de tu tamaño. Si los tiempos en tu hora de más tráfico vuelven a subir a medida que crecen tus datos, aumenta la RAM desde el panel.

Cómo probamos la cuestión de la memoria

DreamHost midió las cifras de memoria en una VM de prueba (arm64), no en un servidor de DreamHost. Un límite estricto de memoria hizo las veces de la RAM de cada plan de MySQL VPS. Hicimos la prueba el 19 de octubre de 2026 para nuestra guía de dimensionamiento de RAM, y esta página reutiliza sus resultados. La VM ejecutaba Ubuntu 24.04 en Colima sobre un Mac, con 2 vCPU y sin swap. MySQL 8.4.11 se ejecutó desde la imagen oficial de Docker con su configuración predeterminada, salvo el tamaño de la caché. sysbench generó una carga mixta de lectura y escritura centrada en un núcleo de filas muy consultado, con 8 hilos a un ritmo constante de 360 transacciones por segundo y una ventana de medición de 3 minutos tras un periodo de calentamiento.

La página de MySQL VPS indica MySQL 8.0, y el artículo del Centro de ayuda de DreamHost Uso de palabras reservadas en MySQL 8 explica que, en un VPS, puedes pedir al soporte una actualización a MySQL 8.4. Nosotros probamos la 8.4, así que un servidor que siga en la 8.0 puede comportarse de forma algo distinta.

Lo que no probamos: la configuración propia de DreamHost para MySQL VPS, el MySQL compartido, los tiempos de Query Monitor en una cuenta real, la red entre un servidor web y un MySQL VPS, las tablas de WordPress o WooCommerce, ni cuánto tarda la migración. Cada celda se ejecutó una sola vez. Los pasos de diagnóstico y los detalles del producto proceden del Centro de ayuda y de las páginas de producto citadas en las fuentes.

Preguntas frecuentes sobre bases de datos lentas