Antes de tocar la base de datos, identifica la página, el plugin o la tarea automática que consume más recursos para evitar limpiezas inútiles o errores.
✉
¿Quieres más información? Escríbenos y te orientamos
Mide la consulta lenta antes de limpiar la base de datos
Una consulta SQL es la petición que WordPress hace a la base de datos para buscar entradas, productos o usuarios. Antes de limpiar tablas, debes medir una URL lenta.
Señales de que el problema es SQL
Las consultas lentas suelen aparecer en una acción concreta: buscar pedidos, filtrar productos, abrir una categoría grande o entrar al escritorio. Si la portada, el contacto y el blog son ágiles, pero el listado de productos tarda mucho, hay una pista clara que revisar.
Cuando la lentitud viene de otro sitio
Síntoma observado Primera herramienta Acción segura Cuándo pedir ayuda Una URL tarda más de 2 segundos Query Monitor Anotar consulta y plugin asociado Si supera 0,2 s de forma repetida Toda la web es lenta Panel del hosting Revisar CPU, memoria y caché Si hay picos continuos de recursos Escritorio lento al buscar pedidos Query Monitor y registro lento Probar en staging Antes de crear índices
Usa query monitor para encontrar el plugin responsable
Query Monitor relaciona una consulta lenta con la URL y el plugin, tema o función que la llama, evitando desactivar extensiones o borrar datos al azar.
Los cuatro datos que debes apuntar
Apunta la URL exacta, la acción que haces, el tiempo de la consulta y el nombre del componente señalado. Por ejemplo: “/tienda/, filtro de talla, 0,38 segundos, plugin de filtros”. Con esos cuatro datos, el soporte técnico puede reproducir el problema sin adivinar.
Qué hacer según el componente detectado
Una limpieza no es una prueba de causa. Si una página lenta mejora tras borrar transients, repite la prueba al día siguiente. Si el retraso vuelve al ejecutar el mismo filtro o proceso, el origen puede seguir siendo el plugin, una consulta repetida o la falta de caché de objetos.
En WooCommerce, revisa wp_postmeta con prudencia
WooCommerce concentra muchas consultas lentas en wp_postmeta , donde WordPress guarda datos extra de productos, pedidos y otros contenidos.
Limpiezas seguras con WP-Optimize
WP-Optimize sirve para revisar revisiones de entradas, comentarios spam, papelera y transients caducados. Un transient es un dato temporal, como una nota pegada en el mostrador, que un plugin guarda para no recalcular algo de inmediato.
Antes de limpiar, revisa qué casillas marcas y usa una copia completa de archivos y base de datos. No borres pedidos, usuarios, formularios, tablas de plugins ni metadatos solo porque ocupen espacio. Si guardan datos personales, también debes respetar el Reglamento General de Protección de Datos, la LOPDGDD y los plazos legales aplicables.
💡
Puede interesarte
Un libro práctico sobre WordPress y SQL puede servirte para entender informes de soporte antes de modificar tu tienda. Resulta útil si quieres reconocer términos como índice, caché de objetos o staging sin depender de comandos copiados.
Ayuda a distinguir una limpieza de datos de una mejora real de consultas
Permite preparar preguntas concretas para el soporte del hosting o desarrollador
Ofrece contexto para interpretar tablas, índices y planes de ejecución
Ver opciones en Amazon →
Lo que no arregla OPTIMIZE TABLE
OPTIMIZE TABLE reorganiza físicamente una tabla en ciertos motores de MySQL o MariaDB. Puede recuperar espacio tras muchos borrados, pero no hace más inteligente una consulta con SELECT *, un ORDER BY sin apoyo o un filtro que lee toda la tabla.
Ruta segura ante una consulta lenta
1. Medir URL
→
2. Hallar origen
→
3. Copia y staging
→
4. Probar y revertir
No pases del paso 2 al 4: una prueba en staging protege pedidos, usuarios y configuraciones activas.
El ajuste del SQL debe reducir los datos leídos, no solo reorganizar tablas.
Por ejemplo, sustituir SELECT * por las columnas necesarias evita transportar campos que la pantalla no usa.
Una consulta de productos con ORDER BY debe ordenar por una columna respaldada por el filtro y el índice disponible, en lugar de ordenar miles de resultados para devolver solo 20 con LIMIT 20. Para paginaciones profundas, un OFFSET 5000 obliga a descartar muchas filas.
Una paginación por cursor, basada en la fecha o el ID del último resultado, suele escalar mejor.
En WooCommerce lento, revisa asimismo los JOIN y GROUP BY introducidos por filtros y detecta consultas N+1: cargar 30 productos y pedir después un metadato por cada uno multiplica accesos a wp_postmeta. La caché de objetos puede reducir lecturas repetidas, pero no sustituye una consulta de productos mal planteada ni recursos del hosting insuficientes.
✉
¿Quieres más información? Escríbenos y te orientamos
EXPLAIN e índices: dónde debe entrar un desarrollador
EXPLAIN muestra el plan que MySQL o MariaDB prevé seguir, y sirve como radiografía antes de añadir un índice SQL para acelerar búsquedas concretas.
Cómo leer un plan sin ejecutar cambios
Un plan puede mostrar key, el índice elegido, y rows, las filas estimadas. Si una consulta filtra por meta_key y después ordena por otro campo, un índice compuesto puede ayudar, pero el orden de sus columnas importa: primero suelen ir las condiciones de igualdad y después las de rango u ordenación.
Anti-patrones que debe corregir el código
Una consulta mejor evita SELECT * si solo necesita dos columnas, porque traer datos que no se van a mostrar añade trabajo. También evita aplicar funciones sobre una columna indexada, como transformar fechas dentro del filtro, ya que el índice puede dejar de ser útil.
Un OFFSET muy alto obliga a saltar muchas filas antes de mostrar una página. Los JOIN, uniones entre tablas, y GROUP BY, agrupaciones de resultados, también deben responder a una necesidad concreta. Un índice redundante, que duplica otro ya existente, ocupa espacio y hace más lentas las escrituras.
Para interpretar un plan, ejecuta primero EXPLAIN sobre una copia de la consulta detectada, por ejemplo: EXPLAIN SELECT post_id FROM wp_postmeta WHERE meta_key = '_stock_status' AND meta_value = 'instock';. Revisa type, key y rows: un type de ALL suele indicar que MySQL leerá gran parte de la tabla; key muestra el índice realmente elegido, y rows estima cuántas filas tendrá que revisar. En MySQL, EXPLAIN ANALYZE aporta tiempos y filas reales, pero ejecuta la consulta, por lo que debe usarse en staging o sobre una consulta de solo lectura controlada.
Compáralo con el registro de consultas lentas y con las filas examinadas: una consulta rápida en vacío puede degradar el rendimiento de WordPress cuando la base de datos recibe tráfico real.
Antes de crear un índice, comprueba los existentes con SHOW INDEX FROM wp_postmeta; y confirma mediante EXPLAIN que MySQL lo utiliza en la consulta concreta. En un índice compuesto, el orden no es intercambiable: para un filtro como WHERE meta_key = '_sku' AND meta_value = 'ABC-123', el patrón de búsqueda suele empezar por la columna con igualdad más selectiva según los datos, pero debe validarse con el plan y pruebas repetibles. Un índice que empieza por meta_key puede no ayudar a una consulta que solo filtra por meta_value.
También conviene evitar índices MySQL redundantes: si ya existe uno sobre (columna_a, columna_b), normalmente otro solo sobre columna_a puede ser innecesario, aunque debe revisarse antes de eliminarlo porque otros procesos pueden usarlo.
✉
¿Quieres más información? Escríbenos y te orientamos
Copias, staging y reversión evitan daños innecesarios
Antes de modificar tablas, índices o consultas, prepara una copia completa, un entorno de staging y una reversión escrita para no afectar pedidos reales.
Checklist antes de cualquier cambio técnico
Consulta identificada: tienes URL, tiempo, filas estimadas y plugin o tema asociado.Copia comprobada: puedes restaurarla en staging sin perder archivos ni tablas.Cambio limitado: haces una sola modificación, no varios plugins y comandos a la vez.Prueba repetible: comparas la misma acción antes y después, con caché controlada.Reversión escrita: sabes qué índice retirar, qué ajuste deshacer o qué copia restaurar.Cuándo detenerte y pedir soporte
Detente si la consulta afecta a wp_users, wp_usermeta, pedidos, pagos o datos de clientes. Detente también ante errores de base de datos, bloqueos, ventas activas o si el cambio exige phpMyAdmin, comandos SQL o edición de código.
El soporte del hosting puede facilitar el slow query log , un registro de consultas que tardan más de un límite configurado. Entrega ese registro junto con la versión de WordPress, WooCommerce, PHP, MySQL o MariaDB y los datos de Query Monitor.
No apliques estas acciones como primera medida si tu web es nueva, no hay lentitud medible o el problema viene de imágenes, caché, servidor, tema o servicios externos. Tampoco modifiques consultas SQL, tablas o índices manualmente sin copia de seguridad, staging y un diagnóstico que identifique una consulta concreta.
Resuelve tus dudas
¿Cómo optimizo una consulta SQL en WordPress?
Localiza primero la consulta con Query Monitor, anota su tiempo y el plugin o tema que la genera. Si tarda más de 0,2 segundos de forma repetida, pruébala en staging antes de cambiar código o índices.
¿Qué plugin sirve para consultas lentas?
Query Monitor sirve para detectar el origen técnico de las consultas lentas, mientras WP-Optimize sirve para limpiar datos seleccionados. No instales ambos junto a otros limpiadores para ejecutar tareas duplicadas.
¿Limpiar revisiones acelera mi WordPress?
Puede reducir tamaño y datos sobrantes, sobre todo en webs con años de contenido, pero no corrige una consulta defectuosa. Revisa entre 10 y 20 revisiones antes de borrarlas para confirmar que no necesitas recuperarlas.
¿Puedo añadir un índice a wp_postmeta?
Puedes hacerlo solo tras identificar una consulta concreta y probar el cambio en staging. En WooCommerce, un índice mal elegido puede afectar extensiones, escrituras de pedidos o actualizaciones.
¿Qué significa EXPLAIN en MySQL?
EXPLAIN muestra cómo MySQL o MariaDB planea buscar los datos de una consulta. Si indica muchas filas o no usa una clave útil, un desarrollador debe valorar el código y los índices.
¿Qué es una consulta N+1 en WordPress?
Es una consulta inicial seguida por una consulta adicional para cada elemento mostrado. Por ejemplo, 1 consulta para 30 productos y otras 30 para leer un metadato de cada producto.
¿Cuándo debo mirar el slow query log?
Míralo cuando el problema aparece con tráfico real o no puedes reproducirlo en una sola visita. Pide al hosting un informe de al menos 24 horas para comparar picos y URLs afectadas.
¿OPTIMIZE TABLE arregla una tienda WooCommerce?
No por sí solo. Puede reorganizar una tabla, pero una búsqueda lenta por metadatos seguirá necesitando revisión de consulta, índice, caché o recursos del servidor.
Mide, cambia una cosa y conserva la reversión
Mide primero con Query Monitor, limpia solo datos que entiendes y deja EXPLAIN, índices y cambios de código para un entorno de pruebas.
