¿Cuánta RAM necesita MySQL y qué tamaño de buffer pool?

Esta guía te ayuda a dimensionar un MySQL VPS, el complemento para sitios que ya están en el hosting de DreamHost. MySQL VPS se ofrece en cuatro tamaños, con 500 MB, 1 GB, 2 GB o 4 GB de RAM según la lista de planes del panel de DreamHost. Para ver qué tamaño necesita una base de datos, probamos bases de datos de 460 MB, 1,8 GB y 4,6 GB con la memoria de cada plan en una VM de prueba (no en un servidor de DreamHost) y contamos cuántas lecturas respondió MySQL desde memoria. Una respuesta aceptada en Server Fault fija la caché de MySQL en aproximadamente el 80 % de la memoria del servidor. Nuestros resultados, más abajo, muestran dónde falla esa regla en servidores pequeños. Si en cambio gestionas tu propio servidor de bases de datos en un VPS, estas mismas cifras te indican qué tamaño darle al pool.

No hace falta que toda la base de datos quepa en la RAM. Matthew Boehm, que responde en nombre de Percona en su foro, le dijo a un usuario que una base de datos de 4 TB puede funcionar con 2 GB de RAM a unas 100 consultas de solo lectura por segundo. Si aún no has confirmado que la base de datos es lo que ralentiza tus páginas (un plugin lento o la falta de caché de página pueden parecer lo mismo desde fuera), empieza por nuestra guía para averiguar si tu base de datos está ralentizando tu sitio.

Qué guarda MySQL en el buffer pool de InnoDB

La mayor parte va a una sola caché. InnoDB, el motor que almacena tus tablas, guarda los datos de tablas e índices en su buffer pool a medida que los lee. Si los datos que necesita una consulta ya están ahí, MySQL responde desde la memoria. Si no, MySQL va al disco y expulsa algo más antiguo para hacer sitio. El manual de MySQL advierte que un pool demasiado pequeño no deja de descartar páginas que vuelve a necesitar un momento después.

Su tamaño es un ajuste: innodb_buffer_pool_size. El valor predeterminado de MySQL es de 128 MB en cualquier servidor. Con su ajuste automático para una máquina que solo ejecuta MySQL, MySQL mantiene 128 MB por debajo de 1 GB de memoria y toma la mitad de la memoria entre 1 GB y 4 GB. DreamHost no publica el tamaño de caché que usa cada plan, y un MySQL VPS no ofrece acceso root ni SSH, así que no puedes cambiar ese ajuste tú mismo.

El resto de la memoria de MySQL no se reduce con el plan. En nuestra VM de prueba, MySQL 8.4 con su configuración de serie usaba unos 470 MB antes de ejecutar ninguna consulta, con una caché de solo 128 MB. El propio recuento de MySQL mostraba a dónde iba: además de la caché, un búfer de registro de 64 MB y unos 150 MB para el Performance Schema, el monitor de actividad integrado de MySQL. Bajo carga, una vez llena la caché, el proceso del servidor ocupaba entre 450 y 740 MB más. En un servidor de 4 GB es una parte pequeña. En uno de 1 GB, es la mayor parte de la memoria.

Lo que medimos con la RAM de cada plan

DreamHost hizo esta prueba el 19 de octubre de 2026 en una VM de prueba (arm64, 2 vCPU), con un límite de memoria estricto igual a la RAM de cada plan. No es un servidor de DreamHost, así que interpreta los resultados como lo que cabe en la memoria de cada plan.

Valoramos cada prueba por su tasa de aciertos, el porcentaje de lecturas que MySQL respondió desde su caché. Una base de datos cabe cuando el 99 % o más de sus lecturas salen de la memoria y MySQL no se bloquea. Entre el 95 % y el 99 % va justa. Por debajo del 95 %, la memoria se queda corta. El umbral del 95 % es de Boehm: según él, a partir del 95 % tienes memoria suficiente. El del 99 % es nuestro, más exigente.

Para la base de datos de 1,8 GB, eso significa que unas 35 de cada 1000 lecturas fueron al disco con 1 GB, 17 con 2 GB y 1 con 4 GB.

El tamaño del buffer pool importó tanto como la RAM. Así se comportó la base de datos de 1,8 GB con 2 GB de memoria en cada tamaño de pool que probamos:

Con los 128 MB predeterminados de MySQL, la tasa de aciertos se quedó en torno al 92-96 % en todos los límites, de 1 GB a 4 GB. Una caché de aproximadamente la mitad de la RAM nunca se bloqueó. Con unas tres cuartas partes, MySQL se bloqueó con 1 GB y 2 GB en cuanto la base de datos superó el tamaño de la caché, porque la parte fija que va encima no tenía dónde caber. Con 4 GB, las tres cuartas partes funcionaron bien. Según nuestras pruebas únicas, en un servidor que gestiones tú, lo seguro es empezar con aproximadamente la mitad de la RAM para innodb_buffer_pool_size con 1 GB y 2 GB, y dejar las tres cuartas partes para servidores de 4 GB o más.

Un límite de 512 MB se quedó corto para la configuración de serie de MySQL 8.4. MySQL usaba unos 470 MB antes de ejecutar ninguna consulta, y todas las pruebas se detuvieron al llegar al límite, incluso con la base de datos de 460 MB. VPS basic tiene 500 MB según la lista de planes del panel de DreamHost, y la página de MySQL VPS indica que el servidor viene preconfigurado. Un servidor configurado para usar menos memoria podría rendir mejor que el nuestro de serie. DreamHost no publica la configuración de VPS basic, así que pregunta al soporte para qué es adecuado antes de poner en él una base de datos con mucha actividad.

Por qué importa más la parte activa que el total

En la misma respuesta, Boehm sitúa la parte activa en torno al 10-20 % del total y lo considera lo habitual. Una tienda con tres años de pedidos lee los pedidos de este mes y sus productos activos mucho más a menudo que una factura de 2023. Nuestra carga de prueba funcionaba igual: volvía una y otra vez a un núcleo de filas muy activo, y así una base de datos de 4,6 GB sacó el 97,7 % de sus lecturas de una caché de 2 GB.

Un informe que suma todos los pedidos desde el lanzamiento hace que todas esas filas estén activas a la vez. No probamos ese peor caso, así que no podemos decir cuánto peor sería el resultado. Si tu sitio depende de búsquedas, informes o exportaciones sobre datos antiguos, toma las filas de la tabla como el mejor caso y elige un plan superior.

Revisa tu base de datos antes de elegir

Para los dos primeros pasos solo necesitas el panel y phpMyAdmin, y funcionan con el plan que tienes ahora.

1. Averigua en qué servidor MySQL estás

   Abre la página MySQL Databases en tu panel y consulta el nombre del servidor en la parte superior. El artículo del Centro de ayuda de DreamHost sobre cómo ver los registros de la base de datos explica los nombres: uno que empieza por iad1 es MySQL compartido, y sql seguido de un número significa que ya estás en un servidor MySQL privado.

2. Mide el tamaño de tus bases de datos

   Ejecuta esta consulta en la pestaña SQL de phpMyAdmin o por SSH. Procede del artículo del centro de ayuda de DreamHost sobre cómo optimizar una base de datos y muestra los datos y los índices de cada base de datos en MB.

   sqlCopiar

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

3. Busca la fila que corresponde a tu total

   Suma todas las bases de datos de tu cuenta, ya que el centro de ayuda de DreamHost indica que se trasladan todas al nuevo MySQL VPS. Busca ese total en la tabla anterior. Si queda entre dos filas, elige el plan de la fila mayor. Así dejas margen para que los datos crezcan. No medimos bases de datos reales de WordPress ni de WooCommerce, así que la cifra que debes usar es tu propio total.

4. Comprueba la tasa de aciertos tras el cambio

   Un MySQL VPS solo ejecuta tus bases de datos, así que sus contadores reflejan únicamente tus bases de datos. Consulta Innodb_buffer_pool_read_requests y Innodb_buffer_pool_reads con SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; y calcula 1 menos las lecturas divididas entre las solicitudes de lectura. SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; muestra el tamaño de caché que tiene tu plan, en bytes, para que puedas compararlo con la tabla. En nuestra VM de prueba, un usuario con permisos sobre una sola base de datos podía consultar ambos. En MySQL compartido, los contadores abarcan todas las bases de datos de ese servidor; por eso esta comprobación espera hasta después del traslado.

Cuándo subir de plan

Sube de plan cuando la tasa de aciertos baje del 95 % y se mantenga ahí a medida que crecen tus datos. La página de MySQL VPS indica que puedes ampliar la RAM desde el panel de control de MySQL VPS, y el Centro de ayuda de DreamHost explica que la parte no usada del plan anterior se abona en el nuevo.

No pagues por más memoria antes de revisar tus consultas más lentas. Más adelante en el mismo hilo de Percona, el informe de ajuste de un usuario mostraba una tasa de aciertos del 100 % junto a millones de joins que no usaban ningún índice, y la respuesta de Boehm fue breve: No amount of ram will fix a bad query. Nuestra guía para encontrar consultas lentas de MySQL explica cómo localizarlas con Query Monitor y EXPLAIN. Si quieres ajustar un servidor MySQL que gestionas tú, consulta nuestro artículo sobre cómo mejorar el rendimiento de la base de datos en un VPS.

Más de 4 GB de datos activos

Si la parte activa de tus datos supera los 4 GB de VPS enterprise, DreamHost tiene dos opciones más grandes. Un servidor dedicado incluye 16 GB de RAM o más y ejecuta MySQL en la misma máquina que tu sitio. La introducción a MySQL del centro de ayuda de DreamHost indica que es adecuado para software que mueve grandes cantidades de datos entre la aplicación y MySQL, y la página de MySQL VPS señala que ahí tienes acceso a los archivos de configuración de MySQL. Si prefieres gestionar tu propio servidor de bases de datos, un VPS llega hasta 32 GB de RAM con Stack 32, donde instalas MySQL y configuras tú mismo el buffer pool.

Si estás valorando una base de datos en la nube, nuestra guía sobre los precios de RDS for MySQL frente a un servidor MySQL privado compara el coste de ambos.

Cómo lo medimos

DreamHost hizo la prueba el 19 de octubre de 2026 en Ubuntu 24.04.4 con Colima en un Mac con Apple silicon: arm64, 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 caché en prueba y dos opciones que desactivamos (guardar la caché entre reinicios y el registro binario). Un límite de memoria de Docker de 512 MB, 1 GB, 2 GB o 4 GB representaba cada plan. Cada base de datos estaba formada por tablas de sysbench de 1 millón de filas cada una. sysbench 1.0.20 generó una carga mixta de lectura y escritura que favorece un núcleo de filas muy activo, con 8 hilos a un ritmo constante de 360 transacciones por segundo. Cada prueba tuvo un calentamiento de 2 minutos (5 para la base de datos de 4,6 GB) y una ventana de medición de 3 minutos. Cada caché se probó con 128 MB, aproximadamente la mitad y aproximadamente tres cuartas partes de la memoria.

La prueba tiene sus limitaciones. Un MySQL VPS se ejecuta en su propio contenedor Linux en el hardware de DreamHost, y DreamHost no publica el tamaño de caché, el límite de conexiones ni el swap de cada plan, así que en un MySQL VPS no verás cifras idénticas. Cada configuración se probó una sola vez, por lo que no podemos mostrar cuánto variaría una repetición, y las diferencias pequeñas pueden ser ruido. No probamos el peor caso en el que todas las filas tienen la misma actividad, ni medimos la memoria por conexión, ni dimensionamos bases de datos reales de WordPress o WooCommerce, ni probamos MySQL 8.0.

Preguntas frecuentes sobre la memoria de MySQL