Slow Queries - woher?

Ich habe eine Kategorie welche den Server immer wieder zum Absturz bringt (Oberkategorie) sobald Last auf den Server kommt und der Cache nicht aufgewärmt ist. Habe mir das ganze mal mit JMeter angeschaut (50 Req. innerhalb einer Sekunde) und alle anderen Kategorien brauchen 2-3 Sekunden und volle CPU Last. Nur diese eine (7000 Produkte (die anderen ca. 3500-4500) ) tickt aus und die CPU hängt sich ziemlich auf und brauch 60-70sek um von 100% Last runter zukommen (I7 Intel Quadcore @ 3.4GHZ).

Dazu das passende Slow Query was ich erhalte - interessant, dass mir die den max Preis ausgibt (min in der Kategorie ist 0.90€ und Max ist 3784€) - jemand eine Idee?

Time: 2017-09-24T19:22:42.769898Z

User@Host: root[root] @ localhost  Id: 12995

Query_time: 14.137540  Lock_time: 0.005553 Rows_sent: 1  Rows_examined: 722803

SET timestamp=1506280962;
SELECT MIN(ROUND(IFNULL(customerPrice.price, defaultPrice.price) * ((100 - IFNULL(priceGroup.discount, 0)) / 100) * (( (CASE tax.id  WHEN 1 THEN 19  WHEN 4 THEN 7  WHEN 5 THEN 2.5  WHEN 6 THEN 8  WHEN 7 THEN 0 END) + 100) / 100) * 1, 2)) as cheapest_price FROM s_articles product INNER JOIN s_articles_details variant ON variant.id = product.main_detail_id
                 AND variant.active = 1
                 AND product.active = 1 INNER JOIN s_core_tax tax ON tax.id = product.taxID INNER JOIN s_articles_categories_ro productCategory3 ON productCategory3.articleID = product.id
            AND productCategory3.categoryID IN (5406) LEFT JOIN s_articles_avoid_customergroups avoidCustomerGroup ON avoidCustomerGroup.articleID = product.id
             AND avoidCustomerGroup.customerGroupId IN (53) INNER JOIN s_articles_details availableVariant ON availableVariant.articleID = product.id
             AND availableVariant.active = 1  LEFT JOIN s_core_pricegroups_discounts priceGroup ON priceGroup.groupID = product.pricegroupID
             AND priceGroup.discountstart = (SELECT MAX(discountstart) FROM s_core_pricegroups_discounts subPriceGroup WHERE subPriceGroup.id = priceGroup.id AND subPriceGroup.customergroupID = ‚53‘)
             AND priceGroup.customergroupID = ‚53‘
             AND product.pricegroupActive = 1 INNER JOIN s_articles_prices defaultPrice ON defaultPrice.articledetailsID = availableVariant.id
             AND defaultPrice.pricegroup = ‚EK‘
             AND IF(priceGroup.id IS NOT NULL, defaultPrice.from = 1, defaultPrice.to = ‚beliebig‘) LEFT JOIN s_articles_prices customerPrice ON customerPrice.articleID = product.id
             AND customerPrice.pricegroup = ‚HP-EK‘
             AND IF(priceGroup.id IS NOT NULL, customerPrice.from = 1, customerPrice.to = ‚beliebig‘)
             AND availableVariant.id = customerPrice.articledetailsID INNER JOIN s_articles_attributes productAttribute ON productAttribute.articledetailsID = variant.id WHERE avoidCustomerGroup.articleID IS NULL GROUP BY product.id ORDER BY cheapest_price DESC LIMIT 1 OFFSET 0;
 

Die Frage ist auch warum so ein Query beim initialen Aufruf der Kategorie aufgerufen wird. Ist das die Standardsortierung?

 

PS: Habe zum testen ALLE Plugins deaktiviert und nutze das Responsive Template.

 

SW Version 5.2.22

Hatte ich auch mal, es hat auch noch zu jede Menge 500er errors in der Google Console geführt.

Ich habe im MySQL den optimizer_search_depth auf 0 gesetzt und das Problem war weg.

Der Datenbank war beim iterieren der Attribute und Filter völlig überlastet gewesen.

 

Probier mal.

@SW5Nutzer schrieb:

Hatte ich auch mal, es hat auch noch zu jede Menge 500er errors in der Google Console geführt.

Ich habe im MySQL den optimizer_search_depth auf 0 gesetzt und das Problem war weg.

Der Datenbank war beim iterieren der Attribute und Filter völlig überlastet gewesen.

 

Probier mal.

 

Damit hatten wir schonmal rumgespielt - allerdings wurden dann andere Queries langsamer. Bzw. die PLT ging hoch.

Hast du das nur für ein Query umgesetzt?