Cuando un cliente informa de pantallas de administración lentas, fallos en los procesos de pago o tiempos de espera aleatorios, las agencias no pueden permitirse el lujo de revisar docenas de tablas o realizar ingeniería inversa del comportamiento de los plugins. Es necesario identificar rápidamente los posibles puntos de fallo y centrar la atención en lo que realmente importa.
En la práctica, la mayoría de los problemas graves de rendimiento y estabilidad se deben a un pequeño número de tablas de bases de datos que crecen sin control con el tiempo. Estas tablas no causan problemas en sitios nuevos o con poco tráfico, pero con años de contenido, plugins y actividad de los usuarios, son responsables de un número desproporcionado de fallos, consultas lentas y solicitudes de soporte técnico urgente.
Este artículo se centra en cinco tablas (y patrones de tablas) de la base de datos de WordPress que las agencias de mantenimiento deberían supervisar activamente, porque son las que tienen más probabilidades de causar problemas de rendimiento en el mundo real a medida que los sitios crecen.
Por qué las agencias solo necesitan supervisar el 20 % de la base de datos
El principio de Pareto ayuda a explicar muchos patrones operativos, y también se aplica al mantenimiento de las bases de datos de WordPress. Las agencias no tienen problemas de forma uniforme en toda la base de datos. En su lugar, un pequeño subconjunto de tablas representa la mayor parte de las ralentizaciones, caídas y tickets de soporte urgentes relacionados con la base de datos.
Las instalaciones estándar de WordPress crean 12 tablas por defecto. Algunas, como wp_users, wp_links, y las tablas de taxonomía, pueden funcionar durante años sin causar problemas. Éstas no suelen desencadenar las consultas más lentas que bloquean los sitios durante los picos de tráfico.
Sin embargo, las tablas de alto riesgo comparten una característica: pueden dañar los sitios cuando crecen. Un sitio con 100 publicaciones puede funcionar sin problemas con revisiones ilimitadas. Ese mismo sitio, con 10.000 publicaciones y 300.000 registros de revisión, probablemente se bloqueará en cada pantalla de edición. Una tienda de comercio electrónico con 50 productos debería funcionar bien, pero si se amplía a 5.000 productos, las páginas pueden tardar segundos en cargarse.
Cinco patrones de bases de datos que provocan que los sitios de WordPress fallen al crecer
Repasemos cinco patrones que aparecen con frecuencia en el trabajo de mantenimiento de una agencia.
No suponen un peligro inmediato en sitios web pequeños, pero a medida que aumenta el contenido, el tráfico y la actividad de los plugins, se convierten en las fuentes más comunes de consultas lentas, tiempos de espera agotados y problemas de estabilidad.
wp_options: la sobrecarga de autoload podría bloquear los sitios con mucho tráfico.
La tabla wp_options almacena los ajustes del sitio y las configuraciones de los plugins y determina qué opciones carga WordPress en cada petición de página (incluidas las páginas en caché). Entre las columnas, autoload es la más importante:
WordPress carga primero todas las opciones con autoload en la memoria en cada petición. Los sitios con un volumen de autoload reducido pueden gestionar el tráfico con normalidad, aunque a medida que crece la autoload, cada visitante consume más memoria de la que tu servidor asigna por proceso PHP.
Si el tamaño del autoload es demasiado grande (por ejemplo, si supera los 3 MB o más), verás pantallas de administración lentas, fallos de pago durante las ventas y errores 502.
El culpable es casi siempre la configuración de plugins huérfanos o entradas de caché temporales conocidas como transitorios (transients). Con el autoload activado, algunas opciones del plugin que eliminas pueden permanecer en la tabla wp_options, lo que significa que se cargan en cada petición. A través de docenas de plugins durante meses o años, esto acumula datos abandonados que se cargan en cada visita a la página.
La consola SQL de Database Studio que se muestra arriba te permite ejecutar una consulta para comprobar el tamaño de los datos con autoload en bytes:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
También puedes utilizar la consola para realizar cualquier otra consulta que necesites, como ordenar los resultados de la consulta inicial.
Tu plan aquí debería ser revisar los resultados, identificar a qué corresponden las entradas de autoload más pesadas y hacer limpieza (es decir, borrar esas filas).
wp_postmeta: Los sitios de comercio electrónico pueden bloquearse por la sobrecarga de metadatos
La tabla wp_postmeta almacena campos personalizados para entradas, páginas y productos. Cada vez que se guarda el contenido, se pueden añadir nuevas entradas de metadatos. Los plugins, en particular, a menudo adjuntan docenas de campos a una sola entrada o producto.
Por ejemplo, WooCommerce almacena datos de producto en postmeta: variaciones, inventario, detalles de envío y atributos. Un solo producto con variaciones puede generar docenas de entradas de metadatos. Los grandes catálogos de productos crean potencialmente millones de filas de postmeta.
El resultado de una tabla wp_postmeta cada vez más grande es que las pantallas de edición tienen dificultades para cargar los datos, los filtros de productos se ralentizan y las búsquedas se ralentizan al intentar consultar tablas masivas. En general, los errores durante periodos de mucho tráfico suelen deberse a la hinchazón de wp_postmeta.
Utilizando la consola SQL, puedes ejecutar consultas para seleccionar y eliminar datos innecesarios, de forma similar a como lo harías con wp_options. El objetivo es localizar indicadores como tablas postmeta de varios gigabytes, una gran cantidad de meta_keys duplicados y metadatos huérfanos en general. Las opciones de filtrado de Database Studio también son útiles en este proceso:
Por ejemplo, puedes ordenar por meta_key haciendo clic en la flecha de la columna. Esto agrupa claves idénticas para que puedas detectar patrones, como claves de plugins eliminados o campos personalizados no utilizados.
wp_posts: revisiones ilimitadas colapsan las pantallas de edición
La tabla wp_posts almacena el contenido y el historial de revisiones. Por defecto, WordPress guarda cada cambio como una entrada independiente en la base de datos, por lo que la edición regular de contenido genera una cantidad significativa de datos adicionales. Los sitios con extensos historiales de contenido y edición pueden acumular miles de entradas de revisión.
Al principio, tus sitios funcionan bien, pero tener muchas revisiones almacenadas puede hacer que tus pantallas de administración se carguen lentamente al editar entradas. WordPress guarda cada 60 segundos durante la edición; los autoguardados también pueden tener un impacto negativo, ya que las sesiones de edición largas crean docenas de entradas de autoguardado.
Puedes limpiar rápidamente la tabla wp_posts de revisiones (por ejemplo):
A continuación, puedes pasar a la consola SQL para ejecutar una consulta y eliminar las revisiones:
DELETE FROM wp_posts WHERE post_type="revision";
Es recomendable comparar el número de revisiones con el de entradas publicadas: una proporción de un solo dígito es razonable. Además, comprueba si las revisiones representan más de la mitad del total de entradas, ya que esto indica un posible exceso. Las revisiones que aumentan mes a mes sugieren la necesidad de implementar límites, lo que se puede conseguir mediante una rápida edición de wp-config.php.
Tablas de plugins: los formularios y los registros crecen hasta que tus sitios se bloquean
Casi todos los plugins crean tablas de bases de datos personalizadas, pero es más habitual en los plugins de formularios, búsqueda y seguridad. Estas pueden seguir creciendo sin necesidad de mantenimiento integrado.
En concreto, los plugins de formularios suelen almacenar de forma permanente todos los envíos. Por lo tanto, si tus sitios reciben un tráfico constante de envíos a lo largo de los años, acumularás miles de entradas de formularios. Además, las tablas relacionadas con los registros crecen aún más rápido. Los plugins de seguridad registran las acciones de los visitantes, los plugins de analítica realizan un seguimiento de las visitas a las páginas y las herramientas de depuración registran los errores.
Al igual que con muchos problemas relacionados con las tablas de bases de datos, las páginas se bloquean, pero también se observan copias de seguridad lentas de la base de datos y un rendimiento degradado que no se correlaciona con el tráfico. La conexión con la base de datos no siempre será evidente, ya que los síntomas aparecen en áreas no relacionadas.
Busca tablas de plugins que igualen o superen los tamaños de las tablas del núcleo de WordPress; cuanto más grandes sean, más importante será reducirlas. Una consulta SQL te ayudará a localizarlas fácilmente:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Si alguna de ellas es huérfana, puedes eliminarla con seguridad. Sin embargo, aunque está fuera del alcance de este post, si alguna tabla es lo suficientemente grande como para justificar su reducción, pero sigue siendo necesaria en tu sitio, te recomendamos que investigues un poco al respecto, incluso poniéndote en contacto con un desarrollador para pedirle consejo.
Action Scheduler: las tareas fallidas se acumulan y bloquean el proceso de pago.
Action Scheduler básicamente ejecuta tareas en segundo plano para WordPress. Pone las tareas en cola, las procesa de forma asíncrona y almacena los registros de finalización de forma permanente por defecto.
Utilizar WooCommerce es una buena forma de entender cómo Action Scheduler puede causar problemas. Por ejemplo, los tiempos de espera de la pasarela de pago provocan acciones fallidas que persisten en la base de datos y se consultan en cada carga de página para comprobar si hay trabajo pendiente. Puedes extrapolar solo una acción fallida de las miles que genera una tienda WooCommerce típica al mes.
Las Vistas de Database Studio pueden ayudarte a eliminar estas acciones fallidas:
Aquí, dale un título a la vista, elige la tabla wp_actionscheduler_actions y haz clic en el enlace Añadir condición. Esto te permite mostrar sólo las acciones fallidas, haciendo mucho más sencillo eliminarlas de la base de datos.
Cómo gestionar tus tablas de bases de datos importantes de WordPress en 10 minutos al mes
Por el coste de unos pocos minutos al mes, puedes reducir la gestión de la base de datos a lo largo del año. Por supuesto, no es necesario monitorizar ni gestionar muchas de las tablas de la base de datos:
- La tabla
wp_usersrara vez causa problemas, a menos que gestiones sitios de membresía con millones de cuentas. Los datos de los usuarios suelen crecer linealmente sin acumular ninguna hinchazón. - Las tablas de taxonomía (como
wp_terms,wp_term_taxonomy,wp_term_relationships) suelen permanecer estables independientemente del tamaño del sitio.
Entre las cinco tablas problemáticas, es común y esperado encontrar tablas wp_posts extensas en sitios de contenido. Recuerda: el contenido real no es excesivo.
Configuración del flujo de trabajo de monitorización
Exportar las tablas de tu base de datos te permite trabajar con los datos en otras aplicaciones. Puedes hacerlo a través del menú desplegable Más elementos de cualquier tabla:
Sin embargo, puedes lograr muchas cosas en MyKinsta sin exportar. El mejor uso de tu tiempo es automatizar la limpieza y revisar manualmente las métricas de tu base de datos. Las vistas de Database Studio pueden ayudarte a configurar tu análisis.
Por ejemplo, puedes crear una vista personalizada que controle wp_postmeta y añadir filtros para patrones específicos de meta_key que quieras rastrear:
Database Studio te permite crear y guardar snippets en la consola SQL, de modo que puedes configurar una consulta SQL para ordenar todas las tablas por tamaño y acceder a ella siempre que lo necesites:
Algunas de las tablas más grandes deberían ser wp_posts, wp_postmetay wp_options. Te recomendamos investigar cualquier tabla que aparezca por encima de estas.
La monitorización exacta que configures depende de tus sitios y necesidades. Sin embargo, aquí tienes algunas áreas en las que puedes fijarte:
- Filtra la tabla
wp_optionspara ver los registros con autoload activo y comprueba el tamaño total (ya sea mediante consultas SQL o exportando a CSV). Cualquier valor que supere 1 MB debería ser investigado. - Comprueba el tamaño de la tabla
wp_postmetacomparándolo con el del mes pasado, en concreto si hay grandes aumentos de tamaño. - Puedes filtrar post_type dentro de
wp_postspara comparar las revisiones de los posts. Si es necesario, establece un límite dentro dewp-config.php. - Para Action Scheduler, las acciones completadas deberían superar en número a las pendientes o fallidas.
En resumen, utiliza Database Studio para crear las vistas, filtros y fragmentos de consulta que utilizarás a menudo. A continuación, busca métricas «peligrosas» y utiliza otras herramientas para automatizar cualquier limpieza. Por ejemplo, el comando WP-CLI wp transient delete puede ayudarte a limpiar los transitorios no deseados dentro de la base de datos.
De las correcciones reactivas al mantenimiento proactivo de la base de datos
Los problemas de base de datos con los que las agencias se enfrentan más a menudo no son raros ni impredecibles. Son el resultado de patrones familiares. La diferencia entre reaccionar a estos problemas y prevenirlos se reduce al enfoque.
No es necesario inspeccionar todas las tablas ni auditar todas las consultas. Es necesario saber qué partes de la base de datos merecen una atención continua y cómo detectar las primeras señales de alerta antes de que se conviertan en interrupciones del servicio o solicitudes de soporte de emergencia.
Para las agencias de mantenimiento, esto cambia la forma en que el trabajo con bases de datos se integra en tu flujo de trabajo. En lugar de tratar la limpieza de la base de datos como una solución puntual después de que algo falle, se convierte en una comprobación sencilla y repetible.
Si te encuentras con un problema en la base de datos que no puedes resolver, especialmente uno que sólo aparece bajo carga, es importante contar con el soporte adecuado. Para los sitios alojados en Kinsta, nuestro equipo de soporte está disponible 24/7 para ayudarte.
