Dotaz: Mysql dotaz vezme 100% vykonu SQL serveru

[RadekXxX]

Ahoj, mam SQL dotaz:

SELECT HwTime, Person_Id, Description, Direction FROM Events WHERE (System = "0") AND (Direction <> "2") AND (Exist = "1") AND (HwTime IN(SELECT MAX(HwTime) FROM Events WHERE (Exist = "1") AND (Direction <> "2") AND (System = "0") GROUP BY Person_Id)) ORDER BY Name ASC

kdyz ho spustim, tak se muze provadet treba hodinu, "show processlist" ukazuje status "Sending data", tabulka obsahuje asi 50000 zaznamu a vysledek ma asi 1300 radku, tento sql dotaz funguje na desitkach serveru, kdyz udelam dump databaze, vezmu konfiguracni soubor databaze a testuji na jinem mysql nebo mariadb serveru tak mam kompletni odpoved za 0.3 sec, ale na tomto serveru se odpovedi nedockam, kdyz pridam LIMIT 1, tak odpoved trva asi 2 sec, kdyz zvedam LIMIT, tak me prijde, ze delka odpovedi se zveda temer exponencialne.

SQL dotaz ma z tabulky vypsat jedenkrat kazde Person_Id, ktere ma nejaktualneji hodnotu HwTime.

Zajimalo by me, jak dotaz polozit jinak, aby fungoval, ale soucasne take proc nefunguje jenom na jednom konkretnim serveru.

Odpovědi

[Lyco]

Jaký je EXPLAIN? Jaký je na ostatních serverech? Jaký je použitý storage engine? Je na tom serveru nějaká další zátěž? Jaká?

[RadekXxX]

Explain vraci toto:

+----+--------------------+--------+-------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type        | table  | type  | possible_keys | key  | key_len | ref  | rows  | Extra                       |
+----+--------------------+--------+-------+---------------+------+---------+------+-------+-----------------------------+
|  1 | PRIMARY            | Events | ALL   | NULL          | NULL | NULL    | NULL | 54216 | Using where; Using filesort |
|  2 | DEPENDENT SUBQUERY | Events | index | NULL          | ESD  | 19      | NULL |  7015 | Using where                 |
+----+--------------------+--------+-------+---------------+------+---------+------+-------+-----------------------------+

Na serveru (ktery je vyrazne mene vykonejsi), kde se dotaz vykonava bez problemu je explain:

+------+--------------+-------------+--------+---------------+--------------+---------+----------------------------+-------+------------------------------+
| id   | select_type  | table       | type   | possible_keys | key          | key_len | ref                        | rows  | Extra                        |
+------+--------------+-------------+--------+---------------+--------------+---------+----------------------------+-------+------------------------------+
|    1 | PRIMARY      | Events      | ALL    | HwTime        | NULL         | NULL    | NULL                       | 52579 | Using where; Using filesort  |
|    1 | PRIMARY      | subquery2   | eq_ref | distinct_key  | distinct_key | 5       | Events.HwTime              |     1 |                              |
|    2 | MATERIALIZED | Events      | ALL    | NULL          | NULL         | NULL    | NULL                       | 52579 | Using where; Using temporary |
+------+--------------+-------------+--------+---------------+--------------+---------+----------------------------+-------+------------------------------+

Na serveru bezi pouze MySQL, pokud se nespusti tento dotaz, tak je zatizeni do 2%, po spusteni stoupne zatizeni na 50% a pri spusteni dvou techto pozadavku je to 100%, pameti je volne vice jak 3GB. Storage je InnoDB, pred tim byl pouzit MyISAM, ale ten pri spusteni scriptu mel zase ve vypisu procesu "waiting for table level lock"

[Filip Jirsák]

Můžete tam mít jiné indexy, mohou jinak vycházet statistiky, podle kterých se plánuje použití indexů. Může tam být jiná verze databázového stroje, která prostě na základě stejných vstupů zvolí jiný prováděcí plán. Zkusil bych zkontrolovat indexy, zda jsou stejné a zda s nimi není nějaký problém, a nechal bych přepočítat statistiky.

[RadekXxX]

Problemovy server obsahuje standartni balik z Debianu, mysql v5.5.62,

bezene se provozuje server na Win. v5.6.11 (tam to chodi)

navic jsem testoval MariaDb v10.1.38 v Debianu (taky chodi)

navic mysql v5.5.33 v Debianu (taky chodi), tato verze db je nejstarsi

Indexy jsou definovany stejne, udelal jsem mysqldump konkretni databaze, ty indexy jsou i vtom dumpu videt.

Kazdopadne reseni to ma, jak jsem psal nize, zmena SQL dotazu, jenom me zajimalo, jak muze vzniknout takovy rozdil 0,5sec vs. nekolik hodin u identickych dat akorat jiny stroj.

[Filip Jirsák]

Příčina, proč je to tak rozdílné, jsou ty rozdílné prováděcí plány. Některé důvody, proč se mohou prováděcí plány lišit, jsem napsal v předchozím komentáři.

[Peter Golis]

Dosť často sa také niečo stávalo ak chýbali indexy, neboli dobre použité indexy, alebo sa zdrojové dáta nedokázali korektne prečítať z disku. Možnosť že by sa nezmestilo 50k údajov aj s indexami do RAM asi môžeme vylúčiť.

PS: Tie časy, keď ľudia museli uzavrieť v selekte index pomocou doplnenia nezmyselnej podmienky (and 1=1) by mali byť už dávno pasé, i keď to riešenie s pozmeneným selektom môže nasvedčovať niečomu podobnému.

[ET]

mne se to nejak nezda, postni sem vystup "show create table Events" ze zdraveho a "rozbiteho" stroje :)

[Max]

Takto triviální dotaz musí běžet jedna dva. CPU může vyletět kvůli zmršenému IO na storage.
Zdar Max

[dustin]

Nechybí na tom daném serveru indexy? Právě výstup explain je potřeba, jak již tu bylo zažádáno.

[Kit]

Zkusil bych tuto variantu:

SELECT MAX(HwTime) AS HwTime, Person_Id, E.Description, E.Direction
    FROM Events JOIN Event as E ON (Person_Id = E.Person_Id) AND (HwTime = E.HwTime)
    WHERE (Exist = "1") AND (Direction <> "2") AND (System = "0")
    GROUP BY Person_Id
    ORDER BY Name ASC

[RadekXxX]

Hral jsem si stim a tato formulace dotazu vraci vysledek za 0,5 sec

SELECT k.HwTime, k.Person_Id, k.Description, k.Direction FROM Events AS k
  JOIN (SELECT Person_Id, MAX(HwTime) AS max_HwTime FROM Events WHERE (Exist=1 AND Direction <> 2 AND System=0) GROUP BY Person_Id) AS g
  ON (k.Person_Id = g.Person_Id AND k.HwTime = g.max_HwTime) GROUP BY k.Person_Id, k.HwTime ORDER BY k.Name ASC