¿Cómo optimizar la base de datos de WordPress para reducir el tiempo de carga?

WordPress · Rendimiento · Base de datos ⚙️
¿Cómo optimizar la base de datos de WordPress para reducir el tiempo de carga?

Un sitio WordPress puede tener un diseño impecable, imágenes comprimidas, CDN reluciente y un tema “ligero” —esa palabra tan repetida que a veces parece promesa electoral—, pero seguir cargando con la lentitud de un tren antiguo subiendo una montaña. Muchas veces el culpable no está en lo visible. Está debajo: en la base de datos.

La base de datos de WordPress es la memoria del sitio: guarda entradas, páginas, usuarios, comentarios, ajustes, metadatos, pedidos de WooCommerce, sesiones, transients, registros de plugins y una alegre colección de restos que nadie invitó pero que se quedaron a vivir. Optimizarla no es un lujo técnico; es una forma de higiene digital. Como barrer una biblioteca después de años de prestar libros sin anotar quién los devolvió.

En esta guía vamos a ver cómo limpiar, analizar y optimizar la base de datos de WordPress de forma profesional, sin trucos mágicos ni plugins milagrosos de esos que prometen “acelerar un 300%” con el aplomo de un vendedor de crecepelo. Hablaremos de MySQL y MariaDB, de wp_options, revisiones, transients, tablas InnoDB, WP-CLI, WooCommerce, seguridad, copias de respaldo y mantenimiento periódico. Porque el rendimiento web no nace de una sola acción heroica, sino de muchas decisiones pequeñas y sensatas.

Por qué la base de datos influye tanto en la velocidad de WordPress 🚀

Cada vez que alguien visita una página de WordPress, el sistema no sirve simplemente un archivo HTML quieto como una postal. WordPress construye la página. Consulta opciones, obtiene el contenido, revisa permisos, carga menús, widgets, metadatos, configuraciones del tema y datos de plugins. Es una pequeña ópera administrativa ejecutándose en milisegundos.

Cuando la base de datos está limpia, indexada razonablemente y bien servida por el hosting, esa ópera suena afinada. Cuando está inflada, llena de datos obsoletos o sometida a consultas torpes, cada visita se vuelve una procesión: PHP espera, MySQL responde tarde, el navegador bosteza y el usuario se va. Así de elegante y así de cruel.

En términos prácticos, una base de datos desordenada puede afectar a:

• TTFB o Time to First Byte: el tiempo que tarda el servidor en empezar a responder.
• Tiempo de generación de página: especialmente en páginas dinámicas sin caché.
• Panel de administración: entradas, pedidos, productos y usuarios pueden volverse lentos.
• Consultas internas: algunos plugins ejecutan consultas pesadas en cada carga.
• Consumo de CPU y memoria: una consulta mala puede comerse recursos como una langosta en campo verde.

Hay una paradoja curiosa: WordPress es sencillo para publicar, pero complejo para mantener. Esa es su grandeza y su fragilidad. Permite levantar un sitio en una tarde, pero si pasan tres años sin mantenimiento, la base de datos empieza a parecerse a un desván familiar: hay cosas valiosas, sí, pero también cables, facturas viejas, cajas sin etiqueta y una tostadora que nadie recuerda haber comprado.

Antes de tocar nada: copia de seguridad, entorno de pruebas y sentido común 🛡️

La optimización de bases de datos tiene una regla sagrada: no se limpia lo que no se puede restaurar. Antes de borrar revisiones, eliminar transients o ejecutar consultas SQL, conviene hacer una copia completa de archivos y base de datos. Completa significa completa. No “creo que el hosting hace backups”. No “el plugin dice que sí”. Verificable.

Advertencia profesional: nunca ejecutes operaciones de limpieza masiva en producción sin una copia de seguridad reciente y restaurable. En sitios con WooCommerce, membresías, reservas o LMS, un error no borra solo datos: borra dinero, historial y confianza.

Lo ideal es trabajar así:

1. Haz un backup completo desde el hosting, un plugin fiable o línea de comandos.
2. Descarga una copia local o guárdala fuera del servidor principal.
3. Prueba la restauración en staging si el sitio es crítico.
4. Desactiva limpiezas automáticas agresivas durante campañas, lanzamientos o picos de venta.
5. Documenta lo que haces: fecha, herramienta usada, tablas afectadas y resultados.

Una anécdota mínima, casi doméstica: una vez perdí veinte minutos buscando mis llaves mientras las tenía en la mano. Me reí, claro, con esa risa breve de quien se descubre humano. En bases de datos ocurre algo parecido: el error no suele venir de lo desconocido, sino de lo obvio ignorado. El backup que “ya estaba”. La tabla que “seguro no se usa”. El plugin que “solo limpia basura”. Y entonces, zas.

Diagnóstico: cómo saber si tu base de datos está frenando WordPress 🔍

Optimizar sin medir es como podar un árbol con los ojos cerrados: quizá quede mejor, quizá lo dejes sin ramas. Antes de limpiar, conviene identificar dónde está el problema. No todos los sitios lentos tienen una base de datos enferma; a veces el cuello de botella está en PHP, en una API externa, en el hosting, en imágenes enormes o en JavaScript desbocado.

Herramientas útiles para investigar

Indicadores de alerta

• El administrador de WordPress tarda varios segundos en cargar.
• La tabla wp_options tiene autoload excesivo.
• Las tablas wp_postmeta, wp_options o wp_actionscheduler_actions crecen sin control.
• Hay miles o millones de transients caducados.
• El TTFB es alto incluso con imágenes optimizadas.
• WooCommerce tarda demasiado en listar pedidos o procesar el checkout.
• Query Monitor muestra consultas repetidas o lentas asociadas a un plugin concreto.

Una consulta sencilla para ver el tamaño de las tablas puede orientar bastante:

SELECT 
  table_name AS tabla,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS tamaño_mb,
  ROUND(data_free / 1024 / 1024, 2) AS espacio_libre_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

No basta con mirar el tamaño total. Una tabla grande no es necesariamente un problema. Una tienda online con años de pedidos tendrá tablas voluminosas, y eso es normal. El problema aparece cuando el crecimiento no corresponde a datos útiles: logs antiguos, sesiones abandonadas, metadatos huérfanos, acciones programadas completadas hace meses. La diferencia entre archivo histórico y basura digital es, a veces, una política de retención.

Qué puedes limpiar en la base de datos de WordPress 🧹

WordPress acumula datos por diseño. Eso no es un defecto; es parte de su flexibilidad. Pero la flexibilidad sin mantenimiento se vuelve barro. Veamos los residuos más comunes y cómo tratarlos.

1. Revisiones de entradas y páginas

Las revisiones son útiles: permiten recuperar versiones anteriores de una entrada. El problema surge cuando un sitio con cientos o miles de contenidos conserva decenas de revisiones por artículo. Cada revisión se almacena como un registro en wp_posts, con posibles metadatos asociados. Una memoria prodigiosa, sí, aunque a veces recuerde hasta el bostezo.

Para contar revisiones:

SELECT COUNT(*) AS total_revisiones
FROM wp_posts
WHERE post_type = 'revision';

Para eliminarlas manualmente, con copia previa:

DELETE FROM wp_posts
WHERE post_type = 'revision';

También puedes limitar revisiones desde wp-config.php:

define('WP_POST_REVISIONS', 5);

O desactivarlas, aunque no suele ser recomendable en equipos editoriales:

define('WP_POST_REVISIONS', false);

La opción más equilibrada suele ser conservar entre 3 y 10 revisiones. Ni amnesia total ni museo de cada coma cambiada.

2. Borradores automáticos y entradas en papelera

WordPress crea autosaves para evitar pérdidas durante la edición. Bendita precaución. Pero con el tiempo pueden acumularse borradores automáticos, entradas en papelera y contenido descartado.

SELECT post_status, COUNT(*) AS total
FROM wp_posts
GROUP BY post_status
ORDER BY total DESC;

Para vaciar la papelera de entradas y páginas desde WP-CLI:

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

También puedes ajustar el tiempo que WordPress conserva elementos en la papelera:

define('EMPTY_TRASH_DAYS', 15);

3. Comentarios spam y comentarios eliminados

Si tu sitio tiene comentarios abiertos, el spam llega como lluvia fina: no parece grave al principio, pero termina empapándolo todo. Akismet, Antispam Bee o soluciones similares ayudan, pero conviene limpiar de vez en cuando.

SELECT comment_approved, COUNT(*) AS total
FROM wp_comments
GROUP BY comment_approved;

Estados habituales: spam, trash, 0 para pendientes y 1 para aprobados.

DELETE FROM wp_comments
WHERE comment_approved = 'spam';

DELETE FROM wp_comments
WHERE comment_approved = 'trash';

Después, revisa metadatos huérfanos de comentarios:

DELETE cm
FROM wp_commentmeta cm
LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id
WHERE c.comment_ID IS NULL;

4. Metadatos huérfanos

Los metadatos son pequeñas notas asociadas a posts, usuarios, comentarios o términos. Plugins y temas los usan constantemente. Cuando el objeto principal desaparece pero el metadato queda, nace el huérfano: un dato sin casa, como una etiqueta pegada a una maleta que ya no existe.

Metadatos huérfanos de posts:

DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Metadatos huérfanos de usuarios:

DELETE um
FROM wp_usermeta um
LEFT JOIN wp_users u ON u.ID = um.user_id
WHERE u.ID IS NULL;

Metadatos huérfanos de términos:

DELETE tm
FROM wp_termmeta tm
LEFT JOIN wp_terms t ON t.term_id = tm.term_id
WHERE t.term_id IS NULL;

Importante: si tu instalación no usa el prefijo wp_, cambia los nombres de las tablas por el prefijo real. Muchos sitios usan prefijos personalizados por seguridad o por instalaciones múltiples.

La tabla wp_options: pequeña puerta, enorme tráfico 🚪

Si hubiera que elegir una tabla capaz de convertir un WordPress elegante en un elefante con patines, sería wp_options. Allí viven ajustes del sitio, configuraciones de plugins, transients, cachés internas y opciones que se cargan automáticamente en muchas peticiones.

La clave está en el campo autoload. Las opciones marcadas para autocarga se cargan de forma temprana porque WordPress asume que serán necesarias. Esto es razonable para el nombre del sitio, la URL o ajustes esenciales. No lo es tanto para guardar un registro de 4 MB de un plugin que alguien desinstaló en 2021, pero la historia de la informática también es la historia de cosas que nadie limpió porque “no molestaban”. Hasta que molestan.

Cómo medir el peso de opciones autoload

SELECT 
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

No existe una cifra universal, porque depende del hosting, memoria, caché de objetos y tráfico. Aun así, como referencia práctica: si el total de opciones autocargadas supera varios megabytes, merece una revisión. En sitios bien mantenidos, debería ser modesto. En sitios antiguos con muchos plugins, puede crecer hasta cifras absurdas con la calma burocrática de una carpeta olvidada.

Ver las opciones autoload más pesadas

SELECT 
  option_name,
  autoload,
  ROUND(LENGTH(option_value) / 1024, 2) AS tamaño_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

¿Qué hacer con lo que aparezca? No borres a ciegas. Identifica primero:

• Si pertenece a un plugin activo.
• Si es un transient o caché temporal.
• Si corresponde a un plugin desinstalado.
• Si puede cambiarse a autoload = 'no' sin romper funcionalidad.
• Si el plugin ofrece una herramienta interna de limpieza.

En algunos casos, cambiar una opción pesada a no autocargada puede mejorar el rendimiento:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'nombre_de_la_opcion';

Cuidado: no cambies opciones críticas como siteurl, home, active_plugins, template, stylesheet o configuraciones esenciales del núcleo. Una opción mal tocada puede dejar el sitio inaccesible.

Transients: lo temporal que a veces se queda para siempre ⏳

Los transients son datos temporales que WordPress y los plugins almacenan para evitar recalcular información. Bien usados, son aliados del rendimiento. Mal gestionados, se convierten en huéspedes eternos con maleta pequeña y presencia infinita.

Normalmente se guardan en wp_options con nombres como:

• _transient_nombre
• _transient_timeout_nombre
• _site_transient_nombre
• _site_transient_timeout_nombre

WordPress elimina transients caducados cuando se consultan o mediante tareas programadas, pero en sitios con mucho movimiento pueden acumularse. Para borrarlos con WP-CLI:

wp transient delete --expired

Para eliminar todos los transients —útil después de migraciones o cambios importantes, pero no como deporte diario—:

wp transient delete --all

Consulta SQL para contar transients:

SELECT COUNT(*) AS total_transients
FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

En sitios con caché persistente de objetos, como Redis o Memcached, muchos transients no viven en la base de datos sino en memoria. Es una diferencia importante: borrar transients desde la base puede no afectar a los que están en el almacén de objetos. La modernidad, ya se sabe, nos prometió simplificarlo todo y nos regaló más capas.

WooCommerce: optimizar sin romper la caja registradora 🛒

WooCommerce transforma WordPress en una tienda. También transforma la base de datos en una criatura mucho más activa. Pedidos, productos, variaciones, cupones, sesiones, carritos, webhooks, tareas programadas, informes, logs… Todo deja rastro. Y ese rastro puede ser necesario por razones fiscales, comerciales o legales. No todo lo viejo es basura.

Áreas frecuentes de crecimiento

Limpiar sesiones de WooCommerce

WooCommerce incluye herramientas en el panel de administración, generalmente en WooCommerce > Estado > Herramientas. Desde ahí puedes limpiar sesiones de clientes, transients de WooCommerce y otros datos temporales. Es preferible usar estas herramientas antes que ejecutar SQL manual, porque respetan la lógica interna del plugin.

Action Scheduler

Action Scheduler es una biblioteca usada por WooCommerce y otros plugins para ejecutar tareas en segundo plano. Es muy útil, pero si hay fallos de cron, integraciones rotas o tareas que nunca se purgan, sus tablas pueden crecer con entusiasmo botánico.

Para ver estados:

SELECT status, COUNT(*) AS total
FROM wp_actionscheduler_actions
GROUP BY status
ORDER BY total DESC;

Si hay muchas acciones complete antiguas, conviene revisar las herramientas de WooCommerce, WP-CLI o la documentación del plugin que las genera. No elimines acciones pendientes sin entender qué hacen. En una tienda, una “tarea pendiente” puede ser un correo, una sincronización de stock o un pago en proceso. El dato parece frío; el cliente al otro lado no lo es.

Optimizar tablas MySQL/MariaDB: OPTIMIZE, ANALYZE y realidad técnica 🧠

Después de borrar muchos registros, las tablas pueden conservar espacio interno sin usar. En MySQL y MariaDB aparece como Data_free u overhead. Aquí entra la tentación de pulsar “Optimizar tablas” como quien pulsa un botón rojo en una película. Funciona, pero conviene saber qué sucede.

OPTIMIZE TABLE

En tablas MyISAM, OPTIMIZE TABLE reorganiza datos e índices. En InnoDB —el motor habitual en WordPress moderno— suele reconstruir la tabla y actualizar estadísticas. Puede recuperar espacio, especialmente si está activado innodb_file_per_table, pero también puede bloquear o consumir recursos durante la operación según tamaño, versión y configuración.

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;

No lo ejecutes alegremente en una tabla enorme de WooCommerce a mediodía, con campañas activas y el dueño de la tienda mirando Analytics como quien mira el pulso de un paciente. Programa estas operaciones en horas de bajo tráfico.

ANALYZE TABLE

ANALYZE TABLE actualiza estadísticas que el optimizador de MySQL/MariaDB usa para decidir cómo ejecutar consultas. No limpia basura, pero puede ayudar a que el motor elija mejores planes de ejecución.

ANALYZE TABLE wp_posts, wp_postmeta, wp_options;

CHECK y REPAIR

CHECK TABLE revisa tablas. REPAIR TABLE se usa sobre todo con MyISAM; en InnoDB, si hay corrupción, el camino suele ser más delicado y puede requerir restauración, revisión de logs o intervención del proveedor de hosting.

CHECK TABLE wp_posts;
REPAIR TABLE wp_posts;

Dato clave: WordPress usa mayoritariamente InnoDB en instalaciones actuales. MyISAM quedó como una reliquia de otra época: rápido en ciertas lecturas simples, pero sin transacciones ni bloqueo a nivel de fila. La vieja velocidad contra la integridad moderna; una antítesis muy de bases de datos.

Índices: cuando una búsqueda deja de ser una excavación 🗂️

Un índice en base de datos funciona como el índice de un libro. Sin él, MySQL puede tener que revisar demasiadas filas para encontrar lo que busca. Con él, llega antes. Parece sencillo. Lo es y no lo es.

WordPress ya crea índices básicos en sus tablas principales. Añadir índices personalizados puede mejorar consultas específicas, sobre todo en sitios con mucho postmeta, filtros complejos, directorios, inmobiliarias, catálogos enormes o WooCommerce con atributos intensivos. Pero cada índice adicional también ocupa espacio y ralentiza escrituras. El índice es mapa y lastre a la vez.

Antes de añadir índices:

• Identifica una consulta lenta real con Query Monitor, slow query log o EXPLAIN.
• Comprueba si el problema viene de un plugin mal diseñado.
• Prueba el índice en staging.
• Mide antes y después.
• Documenta el cambio para no perderlo en migraciones.

Ejemplo de análisis con EXPLAIN:

EXPLAIN
SELECT post_id
FROM wp_postmeta
WHERE meta_key = '_sku'
  AND meta_value = 'ABC-123';

En WooCommerce, buscar por SKU es un caso típico donde los metadatos importan. Sin embargo, no todos los problemas se resuelven con índices. A veces el verdadero remedio es cambiar el plugin de filtros, activar caché persistente, mejorar el hosting o rediseñar cómo se consultan los datos.

Plugins de limpieza: útiles, pero no sacerdotes del rendimiento 🔌

Existen plugins buenos para limpiar la base de datos de WordPress: WP-Optimize, Advanced Database Cleaner, WP Rocket en parte de mantenimiento, LiteSpeed Cache con herramientas de DB, entre otros. Pueden eliminar revisiones, borradores, transients, comentarios spam y optimizar tablas desde una interfaz cómoda.

La comodidad tiene precio: si no sabes qué está borrando el plugin, delegas criterio. Y el criterio, en mantenimiento web, pesa más que el botón.

Qué debe tener un buen plugin de optimización

• Permitir copia de seguridad previa o integrarse bien con tu sistema de backups.
• Mostrar claramente qué datos se eliminarán.
• Diferenciar entre revisiones, transients, comentarios, metadatos huérfanos y tablas.
• Permitir programar limpiezas con límites razonables.
• No borrar datos de WooCommerce sin advertencias específicas.
• Tener mantenimiento activo y compatibilidad con la versión actual de WordPress.

Los plugins son herramientas, no absoluciones. Un martillo sirve para clavar un cuadro; también para romper una tubería. La diferencia no está en el martillo.

WP-CLI: mantenimiento rápido para quienes no temen la terminal 💻

WP-CLI permite administrar WordPress desde línea de comandos. Para desarrolladores, administradores de sistemas y agencias, es una joya discreta: limpia, exporta, busca, reemplaza, verifica y automatiza. No tiene interfaz bonita. Precisamente por eso no distrae.

Exportar base de datos

wp db export backup-antes-optimizacion.sql

Optimizar tablas

wp db optimize

Reparar tablas

wp db repair

Eliminar transients caducados

wp transient delete --expired

Buscar opciones grandes

wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024,2) AS kb FROM wp_options ORDER BY LENGTH(option_value) DESC LIMIT 20;"

Eliminar revisiones con WP-CLI

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

Consejo: en sitios grandes, evita comandos que generen listas enormes de IDs en una sola ejecución. Trabaja por lotes o usa herramientas específicas para no saturar memoria o bloquear procesos.

Servidor, caché y configuración: la base de datos no vive sola 🏗️

Una base de datos optimizada en un hosting pobre es como un violín Stradivarius tocado en una estación con altavoces rotos. Puede mejorar, sí, pero hay límites. WordPress depende del conjunto: PHP, MySQL/MariaDB, memoria, disco, red, caché y configuración.

Factores del servidor que impactan en la base de datos

• Versión de PHP: usar versiones modernas y soportadas mejora rendimiento y seguridad.
• MySQL/MariaDB actualizado: versiones recientes suelen optimizar mejor consultas y uso de índices.
• Discos SSD/NVMe: reducen latencia de lectura/escritura frente a discos tradicionales.
• Memoria disponible: un servidor sin memoria suficiente recurrirá a disco y todo se volverá pesado.
• InnoDB buffer pool: en servidores dedicados a base de datos, suele configurarse con una parte importante de la RAM disponible; en hosting compartido no tendrás control fino.
• Separación de servicios: en proyectos grandes, separar web y base de datos puede mejorar escalabilidad.

Caché de página y caché de objetos

La mejor consulta SQL es la que no se ejecuta. Ahí entra la caché.

Caché de página: guarda versiones HTML de páginas para servirlas sin reconstruir todo WordPress en cada visita. Es crucial para blogs, sitios corporativos y páginas de contenido.

Caché persistente de objetos: con Redis o Memcached, WordPress puede guardar resultados de consultas y objetos frecuentes en memoria. En WooCommerce, membresías y sitios con usuarios conectados, suele marcar una diferencia notable.

Pero ojo: la caché no cura una base de datos enferma; a veces solo le pone maquillaje. Y el maquillaje, aunque útil en bodas y ruedas de prensa, no sustituye a dormir bien.

WP-Cron, tareas programadas y acumulación silenciosa ⏰

WordPress usa WP-Cron para ejecutar tareas programadas: publicar entradas futuras, limpiar transients, enviar correos, procesar acciones, sincronizar datos. A diferencia de un cron real del sistema, WP-Cron se dispara con visitas al sitio. Si no hay visitas, puede retrasarse. Si hay demasiadas, puede ejecutarse con más frecuencia de la deseada si no está bien controlado.

En sitios profesionales conviene desactivar el disparador interno y usar un cron real:

define('DISABLE_WP_CRON', true);

Luego se configura una tarea cron en el servidor, por ejemplo cada 5 o 10 minutos:

wget -q -O - https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

O con WP-CLI:

wp cron event run --due-now

Si las tareas programadas fallan, algunas tablas crecen. Si crecen, las consultas se vuelven más lentas. Si se vuelven más lentas, las tareas fallan más. El círculo perfecto, tan absurdo y tan humano como esperar que una bandeja de entrada se ordene sola.

Optimización y seguridad: limpiar también reduce superficie de riesgo 🔐

Optimizar la base de datos no es solo acelerar. También es reducir exposición. Plugins desinstalados que dejan opciones sensibles, usuarios antiguos, tokens caducados, sesiones olvidadas, logs con información técnica… Todo eso puede convertirse en material útil para un atacante si el sitio sufre una vulnerabilidad.

Buenas prácticas:

• Elimina plugins y temas que no uses; no basta con desactivarlos eternamente.
• Revisa usuarios administradores y cuentas antiguas.
• Limpia sesiones caducadas si usas plugins de membresía o comercio electrónico.
• No guardes backups SQL dentro de carpetas públicas.
• Protege phpMyAdmin, Adminer y accesos de base de datos.
• Usa credenciales de base de datos con permisos adecuados, no más de los necesarios.
• Mantén WordPress, plugins, tema y PHP actualizados.

La seguridad y el rendimiento suelen presentarse como mundos distintos: una custodia la puerta, el otro abre ventanas. En realidad se encuentran en el mismo pasillo. Un sitio limpio es más rápido y, con frecuencia, más difícil de explotar.

WordPress Multisite: optimizar un edificio, no una habitación 🏢

En una instalación Multisite, cada sitio puede tener sus propias tablas: wp_2_posts, wp_2_options, wp_3_posts y así sucesivamente. Además existen tablas globales de usuarios y red. La optimización requiere más paciencia porque el desorden se multiplica por cada sitio.

Recomendaciones para Multisite:

• Audita tablas por tamaño y por sitio.
• Revisa sitios inactivos o abandonados.
• Controla plugins permitidos en red.
• Vigila especialmente opciones autoload en cada blog.
• Automatiza tareas con WP-CLI usando --url=.

wp site list --field=url

wp --url=https://ejemplo.com/sitio1 transient delete --expired

Multisite tiene una belleza administrativa: centraliza. También una sombra: centraliza los errores. Un plugin pesado activado en red puede convertir la eficiencia en epidemia.

Errores comunes al optimizar la base de datos de WordPress ⚠️

La mayoría de desastres no vienen de operaciones sofisticadas, sino de impulsos sencillos. Estos son los tropiezos habituales:

Plan profesional de mantenimiento para una base de datos WordPress saludable 📅

La optimización no debería ser una ceremonia anual con incienso y miedo, sino una rutina. Un sitio bien mantenido envejece mejor. Y en Internet, envejecer bien ya es una forma de resistencia.

Mensualmente

• Crear y verificar copias de seguridad.
• Eliminar comentarios spam y papelera.
• Borrar transients caducados.
• Revisar actualizaciones de WordPress, plugins y tema.
• Comprobar errores PHP y logs del servidor.

Trimestralmente

• Auditar tamaño de tablas.
• Revisar opciones autoload pesadas en wp_options.
• Eliminar revisiones antiguas manteniendo un número razonable.
• Limpiar metadatos huérfanos.
• Revisar plugins desinstalados que dejaron tablas u opciones.
• Medir TTFB y rendimiento con herramientas como WebPageTest, PageSpeed Insights o GTmetrix.

Semestralmente

• Auditar plugins activos: necesidad, calidad, impacto y mantenimiento.
• Revisar slow query log si el hosting lo permite.
• Evaluar caché persistente de objetos para sitios dinámicos.
• Probar restauración completa en staging.
• Revisar configuración de WP-Cron y tareas programadas.

En WooCommerce o sitios críticos

• Monitorizar Action Scheduler semanalmente.
• Limpiar sesiones caducadas.
• Revisar logs de pasarelas de pago e integraciones.
• Medir rendimiento del checkout sin caché de página.
• Coordinar limpiezas con horarios de baja venta.

Procedimiento recomendado paso a paso ✅

Si quieres una ruta clara, esta sería mi secuencia preferida para optimizar la base de datos de WordPress sin improvisar demasiado:

1. Haz backup completo de archivos y base de datos.
2. Clona el sitio en staging si hay ventas, usuarios o datos críticos.
3. Mide el rendimiento actual: TTFB, consultas lentas, tamaño de tablas.
4. Revisa wp_options y detecta opciones autoload pesadas.
5. Limpia revisiones antiguas, papelera, spam y borradores innecesarios.
6. Elimina transients caducados.
7. Limpia metadatos huérfanos con SQL probado o plugin fiable.
8. Revisa WooCommerce si aplica: sesiones, acciones programadas y logs.
9. Optimiza o analiza tablas en horario de bajo tráfico.
10. Comprueba el sitio: frontend, login, checkout, formularios, búsquedas y panel.
11. Mide de nuevo y compara datos, no sensaciones.
12. Programa mantenimiento periódico con límites prudentes.

Consultas SQL útiles para auditoría rápida 🧾

Estas consultas ayudan a inspeccionar sin modificar. Aun así, ejecútalas con cuidado y cambia el prefijo si tu instalación no usa wp_.

Tablas más grandes

SELECT 
  table_name,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY total_mb DESC
LIMIT 20;

Total de revisiones

SELECT COUNT(*) AS revisiones
FROM wp_posts
WHERE post_type = 'revision';

Opciones más pesadas

SELECT 
  option_name,
  autoload,
  ROUND(LENGTH(option_value) / 1024 / 1024, 2) AS tamaño_mb
FROM wp_options
ORDER BY LENGTH(option_value) DESC
LIMIT 25;

Autoload total

SELECT 
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_total_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

Metadatos de posts huérfanos

SELECT COUNT(*) AS postmeta_huerfanos
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Comentarios spam y papelera

SELECT comment_approved, COUNT(*) AS total
FROM wp_comments
GROUP BY comment_approved;

¿Cuánto puede mejorar el tiempo de carga? 📈

La respuesta honesta es: depende. Y aunque “depende” suene a evasiva de consultor, aquí es la verdad. Si tu sitio tiene una base de datos razonable y el problema principal son imágenes de 4 MB, limpiar revisiones no hará milagros. Si, en cambio, wp_options carga 12 MB en cada petición, hay millones de acciones programadas o un plugin ejecuta consultas sin índice, la mejora puede ser notable.

En optimización WordPress conviene distinguir entre:

• Mejoras perceptibles: el administrador carga más rápido, el checkout responde mejor, las búsquedas tardan menos.
• Mejoras medibles: baja el TTFB, disminuye el tiempo de consulta, se reduce CPU o memoria.
• Mejoras preventivas: hoy no se notan mucho, pero evitan problemas futuros.

La limpieza de base de datos no siempre produce titulares espectaculares. A veces produce algo más valioso: estabilidad. Menos errores intermitentes. Menos picos de CPU. Menos esperas en el panel. La velocidad, cuando es buena de verdad, no presume; simplemente deja de estorbar.

La velocidad también es una forma de respeto

Optimizar la base de datos de WordPress es mirar debajo de la alfombra del sitio. No para avergonzarse del polvo, sino para entender que todo sistema vivo acumula restos: decisiones antiguas, plugins probados una tarde, campañas pasadas, revisiones de textos que ya nadie leerá, sesiones de usuarios que se marcharon sin despedirse.

Un WordPress rápido no se consigue únicamente con un plugin de caché ni con una promesa de hosting “turbo”. Se consigue equilibrando opuestos: conservar lo necesario y borrar lo inútil, automatizar sin perder criterio, acelerar sin romper, simplificar sin empobrecer. Ahí está el oficio.

Haz copias. Mide. Limpia. Revisa wp_options. Controla transients. Respeta WooCommerce. Usa WP-CLI si puedes. Optimiza tablas cuando tenga sentido. Y, sobre todo, mantén una rutina. Porque una base de datos cuidada trabaja como un río despejado: no hace ruido, no pide aplausos, simplemente fluye. 🌿