Prodej projektu Duchod.cz - cena 550 tis Kč. Dále MojeFinance.cz, DuchodovaReforma.cz
Zobrazují se odpovědi 1 až 12 z 12

Pokaždé jiná rychlost dotazu MySQL databáze - Máte s tím někdo zkušenosti?

  1. Zdravím,
    mám eshop s MySQL databází a jedna kategorie, která má nejvíce produktů se načítá dlouho (např. 15s). Po nějaké době se kategorie načte rychle (i na jiném PC), aby opět po několika minutách rychlost této kategorie spadla na 15s. Ostatní kategorie se načítají rychle pořád.
    Využíval jsem MySQL 5.1 a nyní to zkouším na MariaDB 5.5, ale problém stále trvá a rychlost kolísá.
    Netýká se to jen webu, ale pokud testuji rychlost dotazu přímo v phpMyAdminu, výsledek je někdy např. 4s, jindy 0.001s...

    Máte s tím někdo zkušenosti? Jak docílit toho, aby se kategorie zobrazovala pokaždé rychle?

    Dotaz:
    SELECT DISTINCT(produkty.ID) AS id_produkt
    FROM produkty LEFT JOIN produkty_kategorie ON produkty.ID = produkty_kategorie.ID_PRODUKT
    WHERE produkty_kategorie.ID_KATEGORIE = '257' OR produkty_kategorie.ID_KATEGORIE = '293' OR produkty_kategorie.ID_KATEGORIE = '294' OR produkty_kategorie.ID_KATEGORIE = '296' OR produkty_kategorie.ID_KATEGORIE = '483'
    GROUP BY produkty.ID

    Díky

  2. Co se právě děje na Webtrhu?
  3. Zrejme mas problematickych "susedov". Skusil by som vlastne VPS.

  4. predpokladam ze nejakou dobu je vysledek v cache a po nejake case tam jiz neni, tj k tomu rychlonacteni.
    Dale hlavne pak prekontrolovat zda je dobre nastavene indexovani.

  5. Nebude zatížen server, na kterém databáze běží?

  6. A co takhle:

    SELECT produkty.ID AS id_produkt
    FROM produkty
    LEFT JOIN produkty_kategorie
    ON produkty.ID = produkty_kategorie.ID_PRODUKT
    WHERE produkty_kategorie.ID_KATEGORIE IN (257,293, 294, 296, 483)
    GROUP BY produkty.ID


    Zkus jestli ti SQL bere párování přes klíče pomocí EXPLAIN . Tady najdeš ukázku v Phpmyadminu.

    Dobrá poznámka je od "node", na veřejném hostingu ti to můžou blokovat sousedi.

  7. Základní otázka: tu databázi běžíš na svém vlastním stroji, který není vytížen ničím jiným?
    Nemění se ten katalog mezitím?

  8. místo OR použij WHERE produkty_kategorie.ID_KATEGORIE IN ('123', '124', ..

  9. Díky za odpovědi...
    Databáze běží na klasickém hostingu, takže to není pouze náš stroj... je možné že problém je i v tom...
    Zkontroloval jsem indexy a ty jsou v pořádku.
    Zkoušel jsem jersywoo řešení s použitím IN a možná se o trochu zrychlilo...
    Vyházel jsem všechny ostatní dotazy ze stránky a nechal jen ten jeden hlavní a zatím to jde dobře... Uvidíme za chvíli :)

    Každopádně zatím děkuji.

  10. mě se to na wedosu stává taky běžně.. odhaduji to na cache, ale jsitý si nejsem. Nicméně je to očividně běžný jev.
    Otázkou je, zda je to jen u sdílených webhostingů

  11. před sql dotaz dej "explain " a pošli sem výsledek, bez toho není možné dělat jakékoliv ladění výkonu, jak už zmínil jersywoo. Nauč se to používat.

    Kromě již zmíněných rád bych doporučil nepoužívat group by a nechat tam pouze distinct, dotaz se nejspíš zrychlí a bude potřeba méně paměti, stejně tak je zbytečné používat left join a nechat mysql vkládat nulové hodnoty, ale právě z explain se člověk dozví, kde je brzda a co má smysl dělat, doporučení jsou obecná, ale striktně záleží na obsahu a velikosti databáze.
    Kód:
    SELECT DISTINCT produkty.ID AS id_produkt
    FROM produkty 
    JOIN produkty_kategorie  ON produkty.ID = produkty_kategorie.ID_PRODUKT 
    WHERE produkty_kategorie.ID_KATEGORIE IN (257,293, 294, 296, 483)
    PS: pokud produkty_kategorie.ID_KATEGORIE není primární klíč, je nutné používat správný datový typ, pro mysql je rozdíl mezi 257 a '257' a v řadě situací místo přetypování podmínky, přetypovává celý sloupec a to bývá obrovský výkonnostní problém

    ---------- Příspěvek doplněn 07.06.2016 v 17:43 ----------

    protected: u sdílených hostingů je společná table, query, index cache pro celý hosting, častěji se tedy vyprázdní a bude daleko více docházet k cache miss, na druhou stranu u sdíleného hostingu má databázový stroj velké množství paměti a výkonný procesor. Stejné problémy se vyskytují u každé databáze a vždy je potřeba ladit a sledovat, u malých projektů stačí koupit větší stroj, ale u větších už je potřeba ladit a sledovat

  12. a) bez EXPLAIN se nehnete, nějaké koukání "na čas" nemá v zásadě smysl
    b) pokud máte zachovanou integritu, mělo by vám stačit
    Kód:
    SELECT DISTINCT(id_product) AS id_produkt FROM produkty_kategorie WHERE produkty_kategorie.ID_KATEGORIE IN (257,293, 294, 296, 483)
    c) pokud ne, zkusil bych explain i s subselectem
    Kód:
    SELECT produkty.ID AS id_produkt FROM produkty WHERE produkty.ID IN (SELECT produkty_kategorie.id_product FROM produkty_kategorie WHERE produkty_kategorie.ID_KATEGORIE IN (257,293, 294, 296, 483))
    d) viz a) - záleží na tom, jak server provede execution plan. Každopádně pokud vám ten dotaz trvá řádově desítky vteřin, máte tam něco zoufale blbě.

  13. Rád bych poděkoval všem za odpovědi.
    Důkladně jsem to testoval a mohu říci, že co se týče výsledku času dotazu tak nejrychlejší je můj původní dotaz s "produkty_kategorie.ID_KATEGORIE = '257' OR produkty_kategorie.ID_KATEGORIE = '293'". Další možnosti FIND_IN_SET a IN byly delší asi o vteřinu až dvě. Mluvím tedy o výsledku, který zobrazuje phpMyAdmin. Na webu mi příjdou všechny tři možnosti stejně dlouhé a problém v tom nejspíš nebude.
    Zkoumal jsem příkaz EXPLAIN a zde jsou dva podobné dotazy - liší se pouze čísly kategoríí, ve kterých se zboží vyhledává...
    Proto mě zaráží, že výsledky vypadají jinak a netuším co to znamená.
    Vyzná se v tom někdo?

    Link na obrázek
    - první dotaz jde celkem rychle (na webu do tří vteřin), druhý jde na webu minimálně 10 vteřin. Přitom počet produktů je tam podobný (kolem 10tis).

    Děkuji.
    Naposledy upravil Marmir : 20.06.2016 v 10:42

Hostujeme u Server powered by TELE3