Software: Magento Community Catégorie Flat Index a permisMagento URL indexeur en cours joinLeft requête lente dans la catégorie/Flat.php provoque une panne du site
Description du problème: Quand je lance un index complet URL, il faut un très long terme à compléter, ce que je comprends peut être normal dans certaines circonstances. Ce n'est pas la question im poser des questions sur. Pendant l'exécution de l'indexeur, le cache de bloc est invalidé en permanence. Lorsque cela se produit, Magento tente de reconstruire le menu à partir de la table de catégories à plat tout en rejoignant la table de réécriture d'url. Ceci est une partie du noyau dans le fichier Mage/Catalogue/Modèle/ressources/Catégorie/Flat.php
Alors que les pistes indexeur, cette requête montre à plusieurs reprises dans les connexions client mysql.
SELECT `main_table`.`entity_id`, main_table.`name`, main_table.`path`, `main_table`.`is_active`, `main_table`.`is_anchor`, `url_rewrite`.`request_path`, `main_table`.`url_override`, `main_table`.`display_subcategories`
FROM `catalog_category_flat_store_19` AS `main_table`
LEFT JOIN `core_url_rewrite` AS `url_rewrite` ON url_rewrite.category_id=main_table.entity_id AND url_rewrite.is_system=1 AND url_rewrite.product_id IS NULL AND url_rewrite.store_id='19' AND url_rewrite.id_path LIKE 'category/%'
WHERE (main_table.is_active = '1') AND (main_table.include_in_menu = '1') AND (main_table.path like '1/1877/%') AND (`level` <= 3)
ORDER BY `main_table`.`position` ASC
Cette requête est extrêmement lente en raison de joinLeft. Cette jointure est définie dans le fichier mentionné ci-dessus. Lorsque l'indexeur est en cours d'exécution, cette requête expire. Les connexions s'accumulent sur le serveur tout en essayant d'exécuter la même requête pour reconstruire le menu de navigation.
Si je change la requête en un joinInner au lieu d'un joinLeft, le problème disparaît immédiatement. Je ne comprends pas le but d'une jointure à gauche, parce que je pense qu'il est hautement improbable qu'il n'y ait pas de valeur dans cette table, et s'il n'y en avait pas, nous pourrions ne pas vouloir montrer cette catégorie.
J'ai vu au moins quelques autres rapports de ce problème, mais ils sont rapidement balayés avec un problème de performance générique lors de l'exécution d'index ou de cache.
Je ne comprends pas pourquoi cette requête agit très différemment lorsque l'indexeur s'exécute parce que je peux faire un choix complet sur chaque table individuellement dans un laps de temps normal. Seulement avec la jointure gauche combinée avec l'indexeur ce problème arrive. Comprendre que, en général, c'est une requête lente.
Question: Pouvez-vous s'il vous plaît fournir des informations sur la jointure à gauche, pourquoi il est nécessaire car il est très lent. Pouvez-vous également recommander une solution pour résoudre mon problème.
Il y a beaucoup de choses qui se passent ici. L'indexeur invalidera immédiatement le cache, de sorte que toutes les requêtes frontales qui arrivent alors que le bloc nav n'est pas dans le cache essaieront de le reconstruire (les requêtes lancées par le bloc de navigation par défaut de Magento 1.X sont chères) . Le problème est évité dans Magento 2 et les extensions tierces en rendant la navigation HTML générée et mise en cache/stockée ailleurs, n'étant mise à jour que lorsqu'elle est régénérée. Et dans le cas de l'indexeur, invalidé seulement après la mise à jour des données, pas avant qu'il ne s'exécute. – CCoffee