¿Cómo arreglar una base de datos de WordPress lenta: una lista de verificación de 4 pasos?

El panel de administración de WordPress no debería tardar cinco segundos en cargarse. Si lo hace, el problema podría no ser tu plan de hosting ni tus imágenes. Podría ser tu base de datos.

Tu base de datos está acumulando silenciosamente años de datos innecesarios, como transitorios caducados, miles de revisiones de entradas y datos de autoload de plugins que eliminaste hace años.

La mayor parte es invisible en wp-admin y no afecta a lo que ven los visitantes. Pero se acumula y, con el tiempo, ralentiza todo.

He diagnosticado sitios donde un solo plugin activaba 80 consultas a la base de datos por carga de página. El hosting estaba bien. El caché estaba configurado correctamente. Nada de eso marcó la diferencia hasta que se solucionó el problema real de la base de datos.

En esta publicación, te mostraré cómo identificar el cuello de botella, limpiar la hinchazón de la base de datos, arreglar las tablas pesadas que sobreviven a la limpieza y reducir la frecuencia con la que WordPress accede a la base de datos en primer lugar.

Aquí están los puntos clave:

• Un panel de administración lento casi siempre apunta a la base de datos, no a tu hosting o imágenes. El panel de administración omite el caché de página, por lo que es la señal más clara que tienes.
• Las revisiones de entradas, los transitorios caducados, los datos huérfanos de plugins y las opciones de autoload hinchadas son los culpables más comunes, y tienden a ser visibles en wp-admin.
• Query Monitor (gratuito) identifica qué plugin o consulta es el cuello de botella antes de eliminar nada.
• DB Optimizer otorga a tu base de datos una puntuación de salud en cinco categorías y muestra una vista previa completa de lo que se eliminará antes de confirmar una limpieza.
• Los datos de autoload en wp_options deberían mantenerse por debajo de 1 MB. Por encima de eso, cada carga de página conlleva un peso innecesario.
• El caché de objetos con Redis o Memcached puede mejorar significativamente los paneles de administración lentos que el caché de página no puede abordar.
• Ejecuta una pasada de limpieza antes de cada copia de seguridad o migración importante. Una base de datos más pequeña significa una transferencia más rápida y un archivo de copia de seguridad más pequeño.

Tabla de Contenidos

¿Qué Causa la Ralentización de una Base de Datos de WordPress?

Antes de sumergirte en las soluciones, es útil saber con qué te enfrentas. Las bases de datos de WordPress se ralentizan por razones predecibles, y la mayoría de los sitios tienen más de una al mismo tiempo.

Revisiones de publicaciones

Cada vez que guardas o actualizas una entrada, WordPress crea una nueva copia. En un sitio activo, una sola entrada puede tener docenas de copias de revisión almacenadas en la base de datos indefinidamente.

Son invisibles para los visitantes, pero añaden peso a cada consulta contra la tabla de entradas.

Transitorios caducados

Los plugins utilizan transitorios para almacenar temporalmente datos de llamadas a API externas y tareas programadas. Se supone que caducan y se eliminan automáticamente.

A menudo no lo hacen, y los registros caducados se acumulan en la tabla wp_options mucho después de haber cumplido su propósito.

Filas huérfanas y tablas de plugins sobrantes

Cuando se elimina un plugin, sus datos suelen quedarse atrás: campos personalizados, metadatos de usuario, metadatos de publicaciones y, a veces, tablas de bases de datos enteras con el nombre del plugin. Un sitio que ha pasado por una docena de plugins a lo largo de los años arrastra los datos fantasma de cada uno.

Datos de autoload en wp_options

Las opciones marcadas como autoload = yes se cargan en cada solicitud de página antes de que WordPress renderice nada. Los plugins que abusan de esta marca añaden peso a cada carga de página, incluidas las páginas que no tienen nada que ver con ese plugin.

Los datos totales de autoload deberían mantenerse por debajo de 1 MB. Muchos sitios lentos tienen 5 MB o más.

Fragmentación de tablas

Cuando se eliminan filas, MySQL no recupera automáticamente el espacio que ocupaban. Con el tiempo, las tablas se fragmentan y MySQL tiene que trabajar más para leerlas.

Por eso, ejecutar un comando de "Optimizar tabla" puede acelerar las cosas, incluso cuando los datos en sí parecen limpios.

Consultas de plugins lentas o excesivas

Algunos plugins están simplemente mal escritos. Ejecutan docenas de consultas en una sola carga de página, o consultan columnas que no están indexadas, obligando a MySQL a escanear tablas enteras fila por fila en lugar de saltar al registro correcto.

Cómo Arreglar una Base de Datos de WordPress Lenta

Para arreglar una base de datos lenta de WordPress, necesitarás encontrar qué es lo que la ralentiza, eliminar el desorden que la causa, arreglar las tablas que sobrevivan a la limpieza y luego reducir la frecuencia con la que se consulta la base de datos.

Esto es lo que harás:

• Paso 1: Identifica qué está ralentizando tu base de datos: usa el plugin gratuito Query Monitor para ver cada consulta que se ejecuta en tu sitio, cuánto tarda cada una y qué plugin la ha activado.
• Paso 2: Limpia el desorden de la base de datos: usa DB Optimizer para puntuar tu base de datos en cinco categorías de salud, previsualizar exactamente qué se elimina y limpiarla de forma segura con un umbral de retención incorporado.
• Paso 3: Aborda las tablas pesadas: arregla el desorden de autoload en wp_options, habilita WooCommerce HPOS si es relevante, comprueba si hay tablas MyISAM que deberían ser InnoDB y optimiza el sobrecoste de las tablas sin phpMyAdmin.
• Paso 4: Reduce la frecuencia con la que WordPress consulta la base de datos: añade caché de página si aún no lo has hecho, luego habilita la caché de objetos con Redis o Memcached para solucionar la lentitud del panel de administración que la caché de página no puede alcanzar.

Paso 1: Identifica Qué Está Ralentizando Tu Base de Datos

Query Monitor es un plugin gratuito que muestra cada consulta de base de datos que se ejecuta en la página actual, cuánto tarda cada una y qué plugin o tema la ha activado. Instálalo desde el directorio de plugins de WordPress y actívalo como cualquier otro plugin.

Una vez activo, aparece un nuevo elemento en tu barra de administración que muestra el número total de consultas y el tiempo de carga de la página de la pantalla en la que te encuentres. Haz clic en él para abrir el panel completo.

Ve a la pestaña Database Queries. Busca consultas que tarden más de 0.05 segundos y cualquier plugin que genere un número inusualmente alto de llamadas.

Query Monitor nombra directamente el plugin o tema responsable, por lo que no tienes que adivinar.

Si un plugin genera 40 o más consultas por página o tiene consultas que superan constantemente los 0.05 segundos, ese es tu cuello de botella. Desactívalo y vuelve a probar.

Si ninguna consulta individual destaca, el problema es una sobrecarga general distribuida por la base de datos, no un actor específico malicioso. Pasa al Paso 2.

Una cosa a comprobar antes de continuar: Query Monitor solo muestra el comportamiento en la página actual. Ejecútalo en el panel de administración, en una página de producto de WooCommerce si tienes una y en una publicación estándar.

La lentitud a menudo es específica de la página, y un problema de consulta en la página de pago no aparecerá mientras estés mirando el panel de control.

Paso 2: Limpia la Hinchazón de la Base de Datos

La mayoría de la gente se salta la limpieza de la base de datos porque no sabe qué es seguro eliminar. Esa duda es razonable. Eliminar lo incorrecto en una base de datos no se puede deshacer.

DB Optimizer resuelve eso mostrándote exactamente lo que hay en tu base de datos antes de eliminar nada. Lo primero que verás es una puntuación de salud de 0 a 100.

Se desglosa en cinco categorías: sobrecarga de tablas, transitorios, revisiones, tamaño de carga automática y elementos de la papelera. Cada una recibe una barra de progreso y una calificación codificada por colores.

Verde significa que la categoría está en buen estado. Amarillo significa que necesita atención. Rojo significa que está afectando negativamente tu puntuación. Pulsa el botón Actualizar Puntuación en cualquier momento para actualizarla.

Una vez que sepas qué está afectando la puntuación, ve a la pestaña Limpieza. Una barra de resumen en la parte superior muestra el número de elementos disponibles para limpiar y el espacio total recuperable en toda tu base de datos.

Debajo de eso, cada tipo de limpieza (Publicaciones y Páginas, Comentarios, Transitorios y Caché) muestra un recuento de elementos y un tamaño estimado. Puedes ver exactamente con qué te enfrentas antes de que se elimine nada.

DB Optimizer tiene por defecto un umbral de retención de 7 días. Cualquier cosa creada en la última semana está fuera de los límites, independientemente de los tipos de limpieza que hayas seleccionado.

Si te estás preparando para una migración y quieres un comienzo limpio, redúcelo. Si estás trabajando en un sitio sensible y quieres precaución adicional, auméntalo. Establécelo en 0 solo si quieres limpiar todo independientemente de la antigüedad. Tu preferencia se guarda automáticamente.

Después de la limpieza, añade una línea a tu archivo wp-config.php para limitar las revisiones futuras antes de que se acumulen de nuevo:

define('WP_POST_REVISIONS', 3);

Añádela encima de la línea que dice "Eso es todo, deja de editar". Esto limita a WordPress a mantener tres revisiones por publicación en adelante.

DB Optimizer se encarga de lo que ya existe. Esta línea evita que vuelva a aparecer.

Paso 3: Aborda las Tablas Pesadas

La limpieza elimina datos sueltos, pero dos tablas específicas causan lentitud continua incluso después de una limpieza exhaustiva: wp_options y wp_postmeta. El motor de almacenamiento que utiliza tu base de datos también importa aquí.

Datos de autoload en wp_options

DB Optimizer muestra el tamaño de carga automática como una de sus cinco categorías de salud. Si sigue por encima de 1 MB después de ejecutar la limpieza, un plugin está escribiendo activamente opciones de carga automática en cada ejecución. La limpieza elimina entradas antiguas pero no puede evitar que se añadan nuevas.

Usa la pestaña Query Monitor para ver qué se está cargando automáticamente y, a continuación, identifica qué plugin es el responsable. Desactivarlo o contactar a su equipo de soporte es la solución.

Wp_postmeta

Esta tabla almacena datos de campos personalizados y crece rápidamente en sitios con mucho contenido de WooCommerce o ACF.

Query Monitor marcará las consultas a esta tabla si es un cuello de botella constante. Solucionarlo a nivel de consulta es territorio de desarrolladores, pero saber que es el problema es la mitad de la batalla.

Usuarios de WooCommerce: habilita HPOS

Si usas WooCommerce, ve a WooCommerce » Ajustes » Avanzado » Funciones y activa el almacenamiento de pedidos de alto rendimiento.

Esto mueve los datos de los pedidos de wp_postmeta a tablas dedicadas y diseñadas específicamente. Puede acelerar drásticamente las consultas de pedidos en cualquier tienda con más de unos pocos cientos de pedidos.

Después de activarlo, WooCommerce puede pedirte que migres los datos de pedidos existentes. Ejecuta la migración antes de continuar.

Motor de almacenamiento: MyISAM vs. InnoDB

MyISAM bloquea toda la tabla de la base de datos durante cada operación de escritura, lo que provoca colas bajo cualquier carga de escritura significativa. InnoDB solo bloquea la fila específica que se está escribiendo.

WordPress ha optado por InnoDB desde MySQL 5.7, pero los sitios migrados de entornos de alojamiento más antiguos a veces todavía tienen tablas MyISAM.

La pestaña Tablas de DB Optimizer muestra el motor de almacenamiento de cada tabla. Si ves tablas MyISAM, convertirlas a InnoDB es un cambio de SQL de una sola línea, pero vale la pena delegarlo a un desarrollador o preguntar a tu proveedor de alojamiento si pueden manejarlo a través de su panel de control.

Sobrecarga de tablas

DB Optimizer resalta cualquier tabla que tenga sobrecarga y muestra un botón Optimizar junto a ella. Puedes manejarlas individualmente o eliminar toda la sobrecarga a la vez.

Ejecuta esto después de la limpieza, ya que la eliminación de filas es lo que crea la sobrecarga en primer lugar.

Paso 4: Reduce la Frecuencia con la que WordPress Consulta la Base de Datos

Incluso una base de datos limpia y optimizada se consulta en cada carga de página. Las capas de caché interceptan esas consultas para que la base de datos haga menos trabajo en general.

La caché de páginas guarda la salida HTML completa de una página para que WordPress omita la base de datos por completo para esa solicitud.

Si no tienes un plugin de caché, añade uno antes que nada. WP Rocket, W3 Total Cache y LiteSpeed Cache se encargan de esto. La caché de páginas es el cambio de mayor impacto que puedes hacer para los visitantes del frontend.

También deberías activar la caché de objetos. La caché de objetos guarda los resultados individuales de las consultas a la base de datos en la memoria del servidor para que las consultas repetidas accedan a la caché en lugar de a la base de datos.

Las solicitudes de administración, los procesos de pago de WooCommerce y cualquier página que no se pueda almacenar en caché por completo se benefician de ello.

Pregunta a tu proveedor de alojamiento si Redis o Memcached están disponibles. Muchos proveedores de alojamiento de WordPress gestionado incluyen uno o ambos.

Si Redis está disponible, instala el plugin Redis Object Cache y sigue las instrucciones de conexión de tu proveedor de alojamiento. El plugin muestra un estado Conectado cuando funciona correctamente.

No instales Redis Object Cache a menos que tu proveedor de alojamiento proporcione realmente un servidor Redis. Sin una conexión activa, el plugin genera errores y no proporciona ningún beneficio.

Opcional: Comandos WP-CLI para Arreglar una Base de Datos Lenta

Si gestionas WordPress desde la línea de comandos, estos comandos cubren el mismo terreno que los pasos anteriores sin una interfaz de plugin.

wp db optimize

Ejecuta la utilidad de optimización de MySQL en cada tabla de la base de datos.

wp transient delete --expired

Elimina todos los transitorios caducados de wp_options.

wp post delete $(wp post list --post_status=trash --format=ids)

Elimina permanentemente todas las entradas actualmente en la papelera.

wp post delete $(wp post list --post_type='revision' --format=ids)

Elimina todas las revisiones de entradas almacenadas.

Haz una copia de seguridad con Duplicator antes de ejecutar cualquiera de estos. Se ejecutan inmediatamente sin paso de vista previa ni aviso de confirmación.

WP-CLI no proporciona la puntuación de salud, los umbrales de retención o las vistas previas por categoría que sí ofrece DB Optimizer. Simplemente te ofrece un camino más rápido para las mismas tareas de limpieza.

Solución de problemas: Cuando la Base de Datos Sigue Lenta

Si has seguido todos estos pasos y el sitio sigue siendo lento, es probable que uno de estos escenarios sea la causa.

Query Monitor no muestra un culpable obvio

Lo que ves: cada consulta individual dura menos de 0,05 segundos, pero la página sigue cargándose lentamente.

El problema podría ser el volumen total de consultas, no una consulta lenta individual. Doscientas consultas de 0,01 segundos cada una todavía suman dos segundos completos de tiempo de base de datos antes de que se renderice algo.

Comprueba la barra de resumen en Query Monitor. Si el número total de consultas supera las 50-75 en una página estándar, vale la pena investigarlo.

Desactiva los plugins uno por uno, recarga la página después de cada desactivación y observa cómo disminuye el recuento. El plugin que cause la mayor caída es tu objetivo.

El tamaño de Autoload sigue siendo alto después de la limpieza

Lo que ves: DB Optimizer todavía muestra un tamaño de autoload superior a 1 MB después de ejecutar la limpieza.

La limpieza elimina las entradas de autoload caducadas y huérfanas, pero no puede evitar que un plugin escriba nuevas. Si el número sigue aumentando, algo está añadiendo activamente al grupo de autoload en cada solicitud.

Query Monitor muestra cada opción que se carga automáticamente en la página actual. Busca entradas de plugins que no reconozcas o que no uses activamente, luego desactiva esos plugins uno por uno y actualiza la puntuación.

El proceso de pago de WooCommerce sigue siendo lento después de la limpieza

Lo que ves: las páginas de pago tardan entre tres y cinco segundos en cargarse después de la limpieza.

HPOS puede estar habilitado, pero la migración de datos puede no estar completa. Ve a WooCommerce » Estado » Herramientas y busca una opción de Migrar datos de pedidos. Si está ahí, ejecútala.

Las migraciones incompletas hacen que WordPress lea simultáneamente de las estructuras de tablas antiguas y nuevas, lo que es más lento que cualquiera de ellas por sí sola.

Si la migración ya está completa, un plugin en conflicto puede estar forzando a WooCommerce a volver a las tablas de pedidos heredadas. Desactiva los plugins uno por uno y prueba la velocidad del proceso de pago después de cada uno.

El almacenamiento en caché de objetos muestra conectado, pero la administración sigue siendo lenta

Lo que ves: el plugin Redis Object Cache muestra "Conectado", pero las páginas de administración siguen siendo lentas.

Es probable que un plugin esté vaciando la caché de objetos en cada solicitud, lo que anula el propósito de tenerla. Abre Query Monitor y comprueba la caché. Si la tasa de aciertos de la caché es inferior al 80%, algo la está vaciando agresivamente.

Identifícalo desactivando plugins en grupos de dos o tres, comprobando la relación después de cada grupo. Cuando la relación de aciertos aumente, el último grupo que desactivaste contiene el problema.

Nada funciona

Si los cuatro pasos están completos y el rendimiento no ha mejorado, el problema probablemente esté fuera de la propia base de datos. La memoria MySQL insuficiente en el hosting compartido obliga al servidor a usar intercambio de disco en lugar de RAM, lo que ninguna limpieza podrá solucionar.

Contacta a tu proveedor de hosting y pregunta específicamente sobre la asignación de memoria de MySQL y si el registro de consultas lentas del lado del servidor está disponible. Un desarrollador que revise el registro de consultas lentas puede identificar problemas que Query Monitor no puede detectar.

Preguntas Frecuentes (FAQs)

Tu Base de Datos No Se Limpiará Sola

Has hecho algo que la mayoría de los propietarios de sitios de WordPress nunca hacen: diagnosticaste un cuello de botella en la base de datos, limpiaste datos que se han estado acumulando durante años, abordaste las tablas específicas que causan lentitud persistente y redujiste la frecuencia con la que la base de datos tiene que trabajar.

De ahora en adelante, ejecuta la comprobación de estado de DB Optimizer una vez al mes. La hinchazón de la base de datos vuelve gradualmente y una pasada mensual evita que se acumule.

Y ten en cuenta que la optimización modifica permanentemente tu base de datos. Una copia de seguridad antes de empezar es la diferencia entre un error solucionable y uno permanente.

Más de 1.5 millones de profesionales de WordPress utilizan Duplicator para hacer copias de seguridad y migrar sus sitios. El plan gratuito cubre copias de seguridad completas del sitio y tarda unos dos minutos en configurarse. ¡Actualiza para obtener almacenamiento en la nube, copias de seguridad automáticas y un plugin gratuito DB Optimizer con Duplicator Pro!

Si esta guía te ha sido útil, estos artículos también merecen ser marcados.

• Cómo optimizar tu base de datos de WordPress
• Estos son los pasos de reparación de la base de datos de WordPress que seguí yo mismo
• Mantenimiento de la base de datos de WordPress: Qué hacer semanal, mensual y trimestralmente
• Cómo hacer una copia de seguridad de una base de datos de WordPress
• El mejor plugin de optimización de bases de datos de WordPress que he usado (más 3 alternativas)