1) Qué es “higiene de datos” y por qué te importa

Higiene de datos es el conjunto de prácticas para mantener limpio, ligero y útil el ecosistema de información de una web. No hablamos sólo de la base de datos (MySQL/MariaDB), sino del flujo completo: contenidos, registros, archivos, cachés, tareas programadas y métricas. En la práctica, buena higiene significa menos fricción para el servidor, consultas más rápidas, páginas que cargan antes, y una experiencia más estable con picos de tráfico.

La analogía más útil: tu web es un jardín. Si nunca podas ni retiras hojas secas, el jardín se vuelve denso e ineficiente. La poda selectiva y el orden permiten que la energía (recursos del servidor) vaya a lo importante.

El objetivo no es “borrar por borrar”, sino dirigir el crecimiento del dato: establecer límites, ciclos y automatismos para que el sistema no se ahogue con su propio éxito.

2) El ciclo de vida del dato en una web moderna

Todo dato pasa por fases: creación, uso, maduración, poda y archivo. Entender cada fase te permite diseñar reglas que previenen la acumulación tóxica:

• Creación: posts, páginas, productos, usuarios, pedidos, metadatos, revisiones, logs, transients, cachés… Muchos datos los genera el usuario; otros los generan plugins o cron jobs.
• Uso: se consulta el dato (lecturas), se modifica (escrituras) o se invalida (cuando caduca una caché o un transient).
• Maduración: deja de ser tan consultado o pierde relevancia (por ejemplo, revisiones antiguas o transients vencidos que nadie borró).
• Poda: eliminación controlada de lo prescindible: revisiones excesivas, transients caducados, logs viejos, sesiones expiradas, índices obsoletos.
• Archivo: mover a almacenamiento frío (CSV, backups, S3) lo que debes conservar por cumplimiento o auditoría, pero que no necesita estar “en caliente”.

Cuando no hay reglas claras para estas fases, la web se ralentiza. No porque “WordPress sea lento”, sino porque el dato crece sin disciplina.

3) Síntomas de baja higiene: cómo se manifiesta en la realidad

• Páginas que antes cargaban en ~1–2 s ahora tardan 3–5 s o más, sin haber cambiado el tema o el hosting.
• Panel de administración cada vez más pesado, búsquedas internas lentas, informes que tardan “una vida”.
• Plugins de caché que “ya no hacen milagros”; purgas frecuentes para “arreglar cosas” temporalmente.
• Errores 500 esporádicos cuando hay pico de tráfico o múltiples ediciones simultáneas.
• Backups que pesan el doble o el triple que hace seis meses.

Estos síntomas no se resuelven con un único ajuste. Requieren instaurar higiene constante.

4) Métricas y señales prácticas para evaluar la salud

No necesitas ser DBA para tomar decisiones. Empieza con estas señales:

• Tamaño total de la base de datos (MB/GB) y su evolución mensual.
• Tablas “calientes”: cuáles crecen más y por qué (p. ej., wp_options, wp_postmeta, wp_comments, tablas propias de plugins).
• % de opciones autoloaded en wp_options y su peso total (las autoloaded se cargan en cada petición).
• Transients: caducados vs activos. Los caducados deberían desaparecer, pero a veces no lo hacen.
• Revisiones: cuántas por post en promedio y si existe límite.
• Web Vitals (LCP, INP, TTFB) y su correlación con el tráfico y la actividad de la BD.

Una visión mínima semanal te da la foto del rumbo. Si detectas picos, revisa qué se publicó, qué plugin se actualizó o qué campaña disparó el uso.

5) Fundamentos rápidos de bases de datos (sin dolor)

MySQL/MariaDB guardan tus datos en tablas, con índices que aceleran búsquedas. El motor más común hoy es InnoDB, que gestiona bloqueos por fila, transacciones y recuperaciones ante fallos. No necesitas memorizar teoría, pero sí tres ideas:

1. Índices bien diseñados = consultas más rápidas. Índices mal planteados o obsoletos = lastre.
2. Fragmentación: muchas escrituras/eliminaciones pueden fragmentar el almacenamiento. Comandos como OPTIMIZE TABLE ayudan a reorganizar y recuperar espacio (ver documentación oficial de MySQL y MariaDB).
3. Consultas N+1 y metadatos excesivos: cuando el modelo crece sin control, se dispara la cantidad de lecturas y joins. La solución no es “más caché”, sino mejorar el modelo y podar.

Si te interesa profundizar en rendimiento general, la guía de optimización de MySQL es un buen punto de partida.

6) Estrategias de higiene: poda, archivo y límites

La higiene no es un evento, es un proceso continuo. Aplica estas estrategias:

6.1 Poda selectiva

• Revisiones: limita su número por post (p. ej. 10–20) y elimina las más antiguas si ya no aportan valor.
• Transients y cachés: elimina los caducados; investiga por qué no se limpian solos. En WordPress, la Transients API define su ciclo de vida.
• Logs y sesiones: rota y expira. Log eterno = disco lleno y consultas lentas.
• Datos huérfanos: metadatos sin padre (posts borrados), adjuntos sin uso, restos de plugins desinstalados.

6.2 Archivo

No todo debe permanecer “en caliente”. Pedidos históricos, formularios viejos o auditorías pueden ir a almacenamiento frío (CSV, S3, backups versionados). Lo esencial: trazabilidad para poder restaurar y consultar cuando haga falta.

6.3 Límites y políticas

• Límites de revisiones por tipo de contenido.
• TTL (vida) de transients y cachés por tipo de dato.
• Retención de logs y formularios (p. ej., 90 días).
• Ventanas de limpieza y mantenimiento (semanales/mensuales).
• Regla de salida para plugins: si desinstalas, limpias tablas y opciones residuales.

7) Operativa segura: backups, staging y ventanas de mantenimiento

La regla de oro: respaldar antes de tocar. Un backup válido es aquel que has probado restaurar. Flujo recomendado:

1. Snapshot + backup (archivos + BD) antes de limpiar.
2. Prueba en staging cualquier poda agresiva.
3. Ventana de mantenimiento en horario de baja actividad.
4. Monitoreo posterior (errores, tiempo de respuesta, tasa de conversión).

8) Cómo aterrizarlo en WordPress (sin romper nada)

WordPress es un magnífico caso de estudio porque su ecosistema es muy rico y, por eso mismo, susceptible a la acumulación. Aquí tienes un mapa de los focos habituales:

8.1 wp_options y el autoload

wp_options suele ser la tabla “caliente”. Las opciones marcadas como autoload se cargan en cada petición: si pesan demasiado, se resiente todo el sitio. Estrategia:

• Identifica las opciones más pesadas y no autoloadees lo que no se necesite en cada carga.
• Elimina transients caducados que permanecen como opciones (ocurre más de lo que crees). La introducción oficial a la Transients API explica su funcionamiento.

8.2 Revisiones

Las revisiones te salvan la vida, pero miles de ellas pesan. Limitar su número reduce ruido sin perder seguridad. Entiende cómo funcionan en la doc de revisiones.

8.3 Transients (caché temporal)

Los transients guardan caché con caducidad. Si caducan y no se limpian, se acumulan. Revisa su ciclo con la Transients API y aplica un plan de expiración realista (ni eterno ni demasiado corto).

8.4 Cron y tareas programadas

WordPress usa WP-Cron para tareas periódicas. No es “cron real” del sistema: se dispara con visitas. Si tu web tiene poco tráfico o picos irregulares, ciertas tareas pueden retrasarse. Documentación de referencia: WP-Cron y funciones wp_cron() / _wp_cron(). Para probar o gestionar eventos, mira WP-CLI cron. Y si procede, engancha WP-Cron al cron del sistema.

8.5 Orfanatos varios

• Metadatos huérfanos: postmeta sin post padre.
• Adjuntos sin uso: imágenes no enlazadas en ningún contenido.
• Tablas de plugins desinstalados: conviene documentar qué creó cada plugin y cómo revertirlo.

8.6 Optimización física

Tras grandes podas, ejecutar OPTIMIZE TABLE puede recuperar espacio y mejorar I/O en algunos motores. Revisa la documentación de MySQL y MariaDB para entender implicaciones (bloqueos, tiempos, etc.).

9) Tiempo y automatización: tareas programadas y limpiezas

La limpieza manual es frágil. Necesitas una rutina automática (con supervisión humana). Ejemplos:

• Purgar transients caducados cada noche.
• Limitar revisiones antiguas una vez por semana.
• Rotar logs y sesiones a diario.
• Comprobar peso de autoload semanalmente y enviar alerta si supera un umbral.

En WordPress, define eventos con WP-Cron y considera engancharlos a cron del sistema si necesitas exactitud real (ver guía de task scheduler).

10) Tu cronograma de mantenimiento (plantilla práctica)

Diario

• Monitoreo básico (tiempo de respuesta, errores 5xx, alertas).
• Rotación de logs/sesiones.
• Purgar transients caducados (job nocturno).

Semanal

• Limitar revisiones por post (mantener 10–20 últimas).
• Auditar autoload (>1–2 MB es señal de alerta en muchos sitios).
• Revisión de tablas que más crecen.

Mensual

• Archivo de formularios viejos (CSV o similar).
• Eliminación de metadatos huérfanos y tablas de plugins retirados.
• OPTIMIZE TABLE tras podas grandes (en ventana tranquila, con backup).

Trimestral

• Revisión de políticas: ¿los límites y TTLs siguen teniendo sentido?
• Test de restauración de backups (simula desastre).

11) Errores comunes y cómo evitarlos

• Confundir caché con solución: la caché es un parche, no un sustituto de la poda y el buen modelo.
• Purgas compulsivas que “arreglan” pero hipotecan el rendimiento (la caché fría es más lenta).
• Borrar sin backup: nunca.
• Optimizar a ciegas: medir antes y después. Si no, no sabrás qué funcionó.
• Dejar cron a su suerte: si necesitas precisión, tarea del sistema.

12) Checklist rápida para pasar a la acción hoy

1. Haz backup completo (archivos + BD) y pruébalo en staging.
2. Lista tablas más grandes y detecta dónde crecen (options, postmeta, comentarios, tablas de plugins).
3. Recorta revisiones antiguas y fija un límite sostenible.
4. Elimina transients caducados; revisa por qué se acumulan.
5. Baja el peso del autoload en wp_options.
6. Programa tareas recurrentes (purgas, rotaciones, alertas).
7. Tras una poda grande, considera OPTIMIZE TABLE (con ventana y backup).
8. Mide antes/después (TTFB, LCP, peso de BD, tamaño de backup).

13) FAQ: preguntas que siempre aparecen

¿Puedo borrar todas las revisiones sin más?

Mejor limita y conserva un histórico razonable (10–20). Las revisiones son red salvavidas. Aprende su funcionamiento en la documentación oficial.

¿Y si elimino transients y “rompo” algo?

Los transients son caché temporal: si se eliminan, se regeneran. El problema es acumular caducados. Revisa la Transients API para mejores prácticas.

Mi cron “a veces” no corre, ¿es normal?

WP-Cron se dispara con visitas. En sitios con poco tráfico o picos raros, puede no ejecutarse cuando toca. Prueba con WP-CLI o engancha a cron del sistema con la guía de WordPress.

¿De verdad OPTIMIZE TABLE acelera mi web?

Puede recuperar espacio y mejorar I/O tras muchas operaciones; depende del motor y del patrón de uso. Lee las notas de MySQL y MariaDB, y ejecútalo en ventana de mantenimiento, con backup previo.

14) Recursos recomendados

• WordPress Transients API: developer.wordpress.org/apis/transients/
• Introducción a Transients (oficial): developer.wordpress.org/news/…
• WP-Cron (conceptos): developer.wordpress.org/plugins/cron/
• Funciones wp_cron() y _wp_cron(): wp_cron() / _wp_cron()
• WP-CLI: cron: developer.wordpress.org/cli/commands/cron/
• Revisiones en WordPress: wordpress.org/documentation/article/revisions/
• Optimizar tablas (MySQL): dev.mysql.com/doc/refman/…/optimize-table.html
• Optimizar tablas (MariaDB): mariadb.com/docs/…/optimize-table
• Optimización general MySQL: dev.mysql.com/doc/en/optimization.html