Moodle ejecuta habitualmente entre 200 y 500 consultas a base de datos por cada carga de página. Con ese volumen, una base de datos mal configurada no es un detalle menor, es, con frecuencia, el cuello de botella real detrás de un Moodle que “va lento” aunque el servidor en general parezca tener recursos de sobra.
En esta guía vas a ver los ajustes concretos que más impacto tienen sobre el rendimiento de la base de datos de Moodle, y cómo mantenerla optimizada con el tiempo, no solo al instalarla.
El ajuste más importante: el buffer pool de InnoDB
innodb_buffer_pool_size determina cuánta memoria RAM se reserva para mantener en caché los datos e índices más consultados de la base de datos. Cuando el volumen de datos consultados con frecuencia cabe en este buffer, las consultas se resuelven directamente desde memoria, sin necesidad de leer de disco.
La referencia recomendada es fijar este valor en torno al 70% de la RAM disponible en el servidor de base de datos, asumiendo que ese servidor está dedicado principalmente a esta función, sin competir intensamente con otros procesos por la misma memoria.
Los cinco parámetros que de verdad mueven la aguja
Más allá del buffer pool, hay un puñado de ajustes en el archivo de configuración de MySQL/MariaDB (my.cnf en Linux, my.ini en Windows) que concentran casi todo el impacto real sobre el rendimiento de Moodle. Este es un punto de partida orientativo para un servidor dedicado a la base de datos, ajústalo siempre a tu RAM y a tu concurrencia real, no lo copies a ciegas:
[mysqld]
# El más importante: caché en RAM de datos e índices.
# ~70% de la RAM en un servidor dedicado solo a la base de datos.
innodb_buffer_pool_size = 12G
# Durabilidad frente a velocidad de escritura del log de transacciones.
# 1 = máxima seguridad (flush + sync en cada commit).
# 2 = más rápido, arriesga ~1 s de transacciones ante un corte eléctrico.
innodb_flush_log_at_trx_commit = 1
# Cada tabla en su propio archivo .ibd: recupera espacio al optimizar
# y facilita el mantenimiento tabla a tabla.
innodb_file_per_table = 1
# Conexiones simultáneas: Moodle abre una por petición concurrente.
# Ajústalo a la concurrencia medida, no lo infles "por si acaso".
max_connections = 200
# Tablas temporales en memoria. Van SIEMPRE juntos y al mismo valor:
# MySQL usa el menor de los dos, así que subir solo uno no sirve de nada.
tmp_table_size = 64M
max_heap_table_size = 64M| Parámetro | Qué hace | Valor orientativo |
|---|---|---|
innodb_buffer_pool_size | Caché en RAM de datos e índices; el ajuste con más impacto directo | ≈70% de la RAM en un servidor de BD dedicado |
innodb_flush_log_at_trx_commit | Cuándo se vuelca a disco el log de transacciones | 1 (seguro) / 2 (más rápido, menos durable) |
innodb_file_per_table | Un archivo por tabla, para recuperar espacio y mantener tabla a tabla | 1 (activado) |
max_connections | Techo de conexiones simultáneas | Según concurrencia real (p. ej. 150–300) |
tmp_table_size / max_heap_table_size | Tamaño de tablas temporales en memoria antes de tocar disco | Ambos al mismo valor (p. ej. 64M) |
Merece la pena entender qué hace cada uno antes de tocarlo:
innodb_buffer_pool_size: ya lo hemos visto: es la caché en RAM de datos e índices, y el único parámetro que, bien puesto, cambia la percepción de velocidad de forma inmediata. Ojo con el matiz del servidor compartido: si Moodle (web + PHP) y la base de datos conviven en la misma máquina, no puedes darle el 70% a la BD, porque Apache/PHP y el propio sistema necesitan su parte de memoria.innodb_flush_log_at_trx_commit: con1(por defecto y recomendado), cada commit se escribe y se sincroniza a disco: ni una transacción confirmada se pierde ante un corte eléctrico. Con2, el log se escribe en cada commit pero solo se sincroniza a disco una vez por segundo: ganas rendimiento de escritura a cambio de arriesgar hasta ~1 segundo de transacciones si el servidor cae de golpe. Para un Moodle en producción con datos que importan (calificaciones, entregas) quédate en1salvo que sepas exactamente por qué bajas a2.innodb_file_per_table: con el valor1(por defecto en versiones modernas), cada tabla vive en su propio archivo.ibden lugar de dentro de un único fichero monolítico compartido. Esto importa para el mantenimiento: permite recuperar espacio de disco real al optimizar una tabla concreta y facilita gestionar tabla a tabla las más pesadas, como los logs de actividad de Moodle.max_connections: es el techo de conexiones simultáneas. Moodle abre una conexión por cada petición que se procesa a la vez, así que este valor tiene que dar cabida a tu concurrencia real en hora punta. Cuidado con el reflejo de subirlo “por si acaso”: cada conexión reserva memoria, y un valor desorbitado puede agotar la RAM antes de que llegues a usarlo.tmp_table_sizeymax_heap_table_size: definen el tamaño máximo de una tabla temporal que MySQL mantiene en memoria antes de volcarla a disco. Moodle genera tablas temporales en informes, agregaciones del libro de calificaciones y consultas complejas; si se quedan cortas, esas operaciones tocan disco y se ralentizan. El detalle que casi todos pasan por alto: MySQL usa el menor de los dos valores, así que hay que subir ambos a la vez.
Usa siempre InnoDB, no MyISAM
Todas las tablas de una instalación de Moodle deberían usar el motor InnoDB, que ofrece mejor concurrencia, integridad transaccional y rendimiento bajo carga real que motores más antiguos. Si tu instalación es especialmente antigua, puede que algunas tablas heredadas sigan en un motor distinto, merece la pena revisarlo explícitamente.
Cómo encontrar las consultas que realmente penalizan el rendimiento
Activar el registro de consultas lentas (slow query log) es la forma más directa de identificar qué operaciones concretas están consumiendo más tiempo, en vez de optimizar a ciegas ajustes generales que quizás no correspondan al cuello de botella real de tu instalación. Se activa con un par de líneas en la misma configuración de MySQL/MariaDB:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1 # registra toda consulta que tarde mas de 1 s
log_queries_not_using_indexes = 1 # tambien las que no usan indicelong_query_time fija el umbral en segundos: con 1 registras cualquier consulta que tarde más de un segundo, que es un punto de partida razonable; puedes bajarlo (por ejemplo a 0.5) cuando quieras afinar más. La opción log_queries_not_using_indexes es especialmente útil, porque las consultas sin índice son de las que más se degradan al crecer el volumen de datos.
Con el registro en marcha, no leas el log a mano línea a línea: agrégalo. mysqldumpslow viene con MySQL y resume las consultas lentas ordenadas por frecuencia o por tiempo total; y pt-query-digest (de Percona Toolkit) da un informe aún más detallado de qué consultas concentran la carga real. La idea es siempre la misma: gastar el esfuerzo en las dos o tres consultas que de verdad penalizan, no repartirlo a ciegas.
Revisa este registro periódicamente, no solo cuando ya hay una queja de lentitud activa.
Mantenimiento periódico de tablas
Con el tiempo, las tablas de una base de datos activa acumulan fragmentación y estadísticas desactualizadas que pueden beneficiarse de una optimización periódica. Y Moodle es un caso extremo: es una aplicación muy intensiva en lecturas repartidas sobre muchísimas tablas mdl_. Algunas crecen sin parar (mdl_logstore_standard_log (el registro de actividad) puede llegar a millones de filas), mientras que mdl_grade_grades, mdl_context, mdl_user o mdl_sessions se consultan constantemente en cada carga de página. Mantener sanas esas tablas es lo que sostiene el rendimiento del día a día.
Hay dos operaciones que conviene distinguir:
OPTIMIZE TABLEreconstruye la tabla, defragmenta los datos y, coninnodb_file_per_tableactivado, recupera espacio de disco. En InnoDB bloquea la tabla mientras se ejecuta, así que hazlo en horario de bajo uso.ANALYZE TABLEsolo recalcula las estadísticas que usa el optimizador para elegir el plan de consulta. Es mucho más ligero y no reescribe la tabla; ayuda cuando el optimizador empieza a tomar malas decisiones tras un crecimiento grande.
Para no ir tabla a tabla, mysqlcheck recorre toda la base de datos de una vez:
# Optimiza (defragmenta y recupera espacio) todas las tablas de Moodle
mysqlcheck --optimize --databases moodle -u root -p
# O solo actualiza estadisticas del optimizador (mucho mas ligero)
mysqlcheck --analyze --databases moodle -u root -pProgramar esta revisión de forma regular (semanal, por ejemplo, en horario de bajo uso) ayuda a mantener el rendimiento estable en vez de dejar que se degrade progresivamente sin que nadie lo note hasta que ya es notable para los usuarios.
La base de datos manda cuando sube la concurrencia
Un matiz que vemos entrar por soporte una y otra vez: mientras hay pocos usuarios a la vez, casi cualquier configuración “aguanta” y el rendimiento parece bien. El problema aparece en los picos (un examen simultáneo, la apertura de matrícula, el cierre de notas) cuando decenas o cientos de sesiones compiten por las mismas tablas. Ahí la base de datos suele ser el primer componente que se satura, antes que la CPU o la red, porque cada petición dispara sus 200-500 consultas y las escrituras empiezan a esperarse unas a otras.
Por eso afinar la BD no es un ajuste aislado: encaja dentro del cuadro general de rendimiento y optimización de Moodle, y solo tiene sentido sobre una máquina que cumpla los requisitos de servidor para Moodle en RAM y disco. Si el servidor va justo de memoria, ningún valor de innodb_buffer_pool_size va a arreglar el fondo del asunto.
Cuándo separar la base de datos del servidor de aplicación
Como referencia orientativa, cuando la instalación crece más allá de unos 1.000 usuarios activos, conviene considerar separar la base de datos en su propio servidor, dedicado exclusivamente a esa función, para equilibrar mejor la carga entre el procesamiento de peticiones web y las operaciones de base de datos.
Monitorización continua, no solo configuración inicial
Configurar bien estos parámetros una vez no es garantía de que sigan siendo adecuados para siempre. El volumen de datos crece con cada curso nuevo, cada calificación, cada log de actividad, lo que era un buffer pool suficiente el primer año puede quedarse corto conforme la instalación acumula historial. Revisar el ratio de aciertos del buffer pool (cuántas consultas se resuelven desde memoria frente a las que requieren lectura de disco) con regularidad permite anticipar cuándo hace falta ajustar la configuración antes de que el rendimiento se degrade de forma perceptible.
Errores comunes al configurar la base de datos de Moodle
- Dejar
innodb_buffer_pool_sizeen el valor por defecto, muy por debajo del 70% de RAM recomendado en la mayoría de instalaciones reales. - No activar el registro de consultas lentas, optimizando a ciegas sin saber realmente qué operación es la que más penaliza.
- Mantener tablas heredadas en MyISAM en vez de migrarlas a InnoDB.
- No revisar el crecimiento de la base de datos con el tiempo, dejando que un ajuste correcto en el primer año quede desactualizado años después.
- No programar mantenimiento periódico de tablas, permitiendo que la fragmentación se acumule sin control.
Preguntas frecuentes
¿Qué porcentaje de RAM debería asignar al buffer pool de InnoDB? Aproximadamente el 70% de la RAM disponible en el servidor de base de datos, asumiendo que está dedicado principalmente a esta función.
¿MyISAM es peor que InnoDB para Moodle? Sí, en la práctica InnoDB ofrece mejor concurrencia e integridad transaccional, y es el motor recomendado para todas las tablas de una instalación de Moodle.
¿Cómo sé si mi base de datos es el cuello de botella de rendimiento? Activando el registro de consultas lentas y revisando el ratio de aciertos del buffer pool, si muchas consultas requieren lectura de disco en vez de resolverse desde memoria, es una señal clara.
¿Con qué frecuencia debería optimizar las tablas de mi base de datos? Una revisión periódica, por ejemplo semanal, en horario de bajo uso, ayuda a mantener el rendimiento estable frente a la fragmentación acumulada con el tiempo.
¿Cuándo debería separar la base de datos en su propio servidor? Como referencia orientativa, a partir de unos 1.000 usuarios activos, aunque el momento exacto depende también de otros factores de carga específicos de tu instalación.
¿Qué pasa si mi buffer pool era suficiente el año pasado pero ya no lo es? Es un escenario habitual conforme crece el volumen de datos con cada curso y cada calificación acumulada, conviene revisar el ratio de aciertos periódicamente para detectar este desajuste antes de que afecte al rendimiento de forma perceptible.
¿Necesito conocimientos avanzados de bases de datos para aplicar estos ajustes? Los ajustes básicos (buffer pool, motor InnoDB, registro de consultas lentas) son accesibles con conocimiento técnico moderado, aunque un afinado más fino para instalaciones grandes suele beneficiarse de experiencia especializada en administración de bases de datos.
¿Es mejor OPTIMIZE TABLE o ANALYZE TABLE?
No son alternativas, hacen cosas distintas. OPTIMIZE reconstruye la tabla para defragmentarla y recuperar espacio (y bloquea la tabla mientras corre, hazlo en horario de bajo uso). ANALYZE solo actualiza las estadísticas del optimizador y es muy ligero. En el día a día basta con ANALYZE; deja OPTIMIZE para las tablas que más crecen, como los logs, y hazlo con menos frecuencia.
¿Debería bajar innodb_flush_log_at_trx_commit a 2 para ir más rápido?
Solo si entiendes el riesgo. Con 2 ganas velocidad de escritura, pero puedes perder hasta un segundo de transacciones si el servidor se cae de golpe. En un Moodle donde se guardan calificaciones y entregas, ese segundo puede ser el envío de un alumno, así que la recomendación por defecto es dejarlo en 1.
¿Cada cuánto debería mirar el registro de consultas lentas?
Conviértelo en un hábito, no en una reacción. Revísalo cada semana o cada dos con mysqldumpslow o pt-query-digest para ver qué consultas concentran la carga, aunque nadie se haya quejado todavía. Así detectas una consulta que se está degradando por crecimiento de datos antes de que se convierta en una queja real.
Conclusión
La base de datos es, literalmente, el corazón de Moodle, con cientos de consultas por cada página cargada, un ajuste incorrecto del buffer pool o un motor de tabla inadecuado se nota en cada clic de cada usuario. Afinar estos parámetros correctamente, y revisarlos con el tiempo conforme la instalación crece, es una de las inversiones de rendimiento con mayor retorno real.
Si prefieres que alguien afine y monitorice esto por ti, en Avantys lo incluimos como parte de la optimización de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Por qué mi Moodle va lento: causas más comunes
- Requisitos de servidor para Moodle (CPU, RAM, disco)
- Redis para Moodle: caché en memoria explicado
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
