Rendimiento y monitorización

Diagnosticar consultas LEFT JOIN lentas en WordPress

Revisado el 3 min de lectura wordpress rendimiento base de datos

En instalaciones grandes, una consulta de WordPress que filtra por categorías o taxonomías puede tardar mucho al combinar posts y term_relationships, ordenar y limitar resultados. La presencia de LEFT JOIN no demuestra por sí sola que la consulta esté mal: importan datos, filtros, índices y plan de ejecución.

Contexto del caso histórico

Esta guía nació de incidencias con cientos de miles de entradas y remite al ticket 54346 de WordPress, donde se estudian consultas de categorías y alternativas con subconsultas.

Los resultados observados en determinadas instalaciones no garantizan tiempos de milisegundos para cualquier volumen de datos. Tampoco convierten un parche del ticket en una corrección oficial aplicable a todas las versiones.

Identificar la consulta real

  1. Reproduce una URL lenta y registra si había sesión, caché y filtros.
  2. Utiliza PHP X-Ray para localizar la consulta completa y el componente que la genera.
  3. Anota versiones de WordPress, MySQL o MariaDB y plugins implicados.
  4. En una copia con datos representativos, revisa el plan con EXPLAIN y los índices existentes.

Compara cuántas filas se examinan, dónde se filtra y cómo se ordena. Un plan diferente después de una actualización merece análisis, pero no identifica automáticamente un único culpable.

Evaluar una alternativa

El desarrollador puede probar una subconsulta, una expresión equivalente, un índice o una reformulación del uso de WP_Query. Verifica que conserve las mismas entradas, orden, exclusiones, duplicados y paginación, especialmente con combinaciones de taxonomías.

No sustituyas todos los JOIN ni elimines GROUP BY de forma global. Un cambio que acelere una categoría puede devolver resultados incorrectos en otra consulta.

Aplicar y mantener

Evita editar directamente los archivos del núcleo: las actualizaciones sobrescriben los cambios y un parche antiguo puede dejar de encajar. Si una adaptación temporal resulta imprescindible, debe mantenerla el desarrollador con control de versiones, pruebas y una vía de retirada.

Tras el cambio, compara varias ejecuciones y comprueba categorías, búsquedas, paginación y administración. Conserva el plan anterior y revierte si empeoran otras operaciones. Para consultas que también calculan totales, consulta la guía de SQL_CALC_FOUND_ROWS.

También te puede ayudar

¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.