Optimizar la base de datos de WordPress: medir y actuar

Optimizar la base de datos de WordPress empieza por comprobar qué está causando lentitud o crecimiento. No selecciones todas las tablas para reparar y optimizar por rutina: esas operaciones dependen del motor y pueden consumir recursos o bloquear trabajo. Guarda una copia recuperable antes de modificar datos.

Comprueba el sitio y el respaldo

Reproduce el problema con una página o una acción concreta y anota cuándo ocurre. Un sitio lento también puede tener problemas de servidor, plugins o red. Revisa cómo medir el rendimiento de WordPress antes de atribuir toda demora a la base.

Prepara una copia de archivos y base con restauración comprobada. Para una operación que pueda afectar al servicio, acuerda una ventana y prueba primero en un entorno separado. El respaldo no evita una interrupción ni recupera cambios posteriores por sí solo.

Identifica la base y el alcance

Consulta en privado el DB_NAME de wp-config.php y comprueba que coincide con la base elegida en phpMyAdmin. No publiques el archivo ni sus credenciales. Un prefijo de tabla distinto de wp_ es posible; no lo cambies como una optimización de rendimiento.

Las capturas ilustran un panel anterior. En tu instalación identifica motor, tamaño aproximado y tablas relevantes antes de elegir una acción. Si tienes WP-CLI y acceso autorizado, puedes consultar información de tamaño sin pedir una reparación:

wp db size --tables

Que una tabla sea grande no demuestra que sobre. Puede guardar contenido, pedidos, relaciones o datos activos de un plugin. Si el problema es que WordPress no conecta, consulta el diagnóstico de conexión a la base; limpiar tablas no es su reparación general.

Distingue limpieza, optimización y reparación

Una limpieza elimina datos que has decidido no conservar. Una optimización reorganiza estructuras según el motor. Una reparación intenta resolver problemas concretos y no es una tarea preventiva equivalente a las otras dos.

En MySQL, REPAIR TABLE no es el procedimiento de reparación de InnoDB. OPTIMIZE TABLE puede reconstruir tablas y requiere valorar espacio, bloqueos y carga según la versión y el motor. Usar phpMyAdmin o un comando de WP-CLI no elimina esas consecuencias.

Reduce datos solo con una decisión explícita

• Revisa spam y papelera desde WordPress y conserva lo que necesites antes de vaciarlos.
• Decide cuánto historial de revisiones necesitas. Limitar revisiones futuras no equivale a eliminar el historial existente.
• Para transitorios caducados, usa una función que identifique precisamente ese alcance. No borres opciones o toda la caché sin entender para qué se utilizan.
• Antes de retirar tablas de un plugin, comprueba su documentación y sus dependencias. El nombre o el prefijo no acreditan que una tabla esté huérfana.

No se propone una consulta SQL para borrar revisiones o comentarios con sus relaciones. Tampoco cambiar charset, collation o índices por una recomendación genérica: esas decisiones necesitan diagnóstico y compatibilidad con la aplicación.

Comprueba el resultado

Repite la misma acción que mediste y contrasta tiempo, errores y uso de recursos. Verifica acceso al editor, publicación de un borrador y funciones de los plugins implicados. Documenta lo que cambiaste y cómo volver al estado anterior.

No programes reparaciones mensuales como una garantía de velocidad. Si el límite está en recursos o servicio, revisa qué ofrece tu alojamiento con el proveedor en lugar de seguir eliminando información.

Fuentes oficiales

• MySQL: OPTIMIZE TABLE
• MySQL: REPAIR TABLE y motores admitidos
• WP-CLI: tamaño de la base de datos
• WP-CLI: transitorios caducados
• WordPress: wp-config.php