Consulta SQL_CALC_FOUND_ROWS lenta

4

Estamos experimentando un rendimiento muy lento con consultas que usan SQL_CALC_FOUND_ROWS en la sección de administración de WordPress.

Actualmente tenemos alrededor de 125,000 publicaciones en nuestro sitio y utilizamos Varnish para almacenar en caché el front-end y estamos en la versión 4.2.3 de WordPress.

El problema surge cuando hay personas que utilizan la sección de administración de WordPress y WordPress ejecutará una consulta como la siguiente:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID 
FROM wp_posts 
WHERE 1=1 AND (((wp_posts.post_title LIKE '%denali%') 
OR (wp_posts.post_content LIKE '%denali%'))) 
AND wp_posts.post_type = 'post' 
AND (wp_posts.post_status = 'publish' 
OR wp_posts.post_status = 'future' 
OR wp_posts.post_status = 'draft' 
OR wp_posts.post_status = 'pending' 
OR wp_posts.post_status = 'private') 
ORDER BY wp_posts.post_title LIKE '%denali%' DESC, 
wp_posts.post_date DESC LIMIT 0, 20 

¿Hay algún parche para solucionar este problema o algún tipo de filtro pre_get_posts que pueda ejecutar?

Planeo eliminar algunas revisiones de publicaciones y hacer algunas optimizaciones de base de datos, pero primero quería ver si había algún tipo de solución para esto dentro de WordPress.

Me encontré con problemas similares mientras buscaba esto, pero la mayoría de esos problemas parecen tener entre 2 y 6 años.

    
pregunta bigmike7801 04.09.2015 - 22:36

2 respuestas

1

El uso de SQL_CALC_FOUND_ROWS no es realmente un problema, aunque incurre en una sobrecarga.

Lo que sucede es que WordPress usa SQL_CALC_FOUND_ROWS para determinar el total de publicaciones que se hubieran devuelto si no se hubiera proporcionado la cláusula LIMIT . Esto es necesario para calcular y proporcionarle los enlaces de paginación correctos.

Deshabilitarlo incondicionalmente está garantizado para romper las cosas en todo el lugar.

Si puede identificar consultas específicas que sufren su uso, y puede hacerlo sin paginación, entonces podría enlazar a pre_get_posts y establecer condicionalmente el parámetro no_found_rows en verdadero. Esto, sin embargo, es más un truco que una solución.

La solución adecuada es utilizar un mecanismo de almacenamiento en caché de consulta de la base de datos, ya sea en el lado de la base de datos, o en el lado de WordPress, utilizando un complemento como Advanced Post Cache (desarrollado y utilizado en WordPress.com)

    
respondido por el Anastis 22.06.2017 - 21:13
-1

$ query- > set ('no_found_rows', true);

    
respondido por el Younes Nesta 23.02.2017 - 15:09

Lea otras preguntas en las etiquetas