Új hozzászólás Aktív témák

• #1984 SaNyEe aktív tag

  Új Válasz 2018-04-10 14:48:24 #1984

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SaNyEe

  aktív tag

  Sziasztok,

  Találkoztam egy érdekes problémával (mysql "újonc" vagyok, Oracle vonalon mozgok alapvetően)

  Egy Select rettenet hosszú ideig fut, a problémás selectet "redukáltam" a problémás részre. Ennek explainje a következő:

  mysql> explain SELECT a.clock
-> FROM alerts a, events e
-> WHERE e.eventid=a.eventid;
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
| 1 | SIMPLE | a | ALL | alerts_3 | NULL | NULL | NULL | 3723509 | NULL |
| 1 | SIMPLE | e | eq_ref | PRIMARY | PRIMARY | 8 | zabbix.a.eventid | 1 | Using index |
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
2 rows in set (0.00 sec)

  a tábla alerts_3 indexe nem kerül használatba. A csatolt mezők bigint(20) unsigned típusúak. Baloldali tábla 166 millió, a jobboldali tábla 3,7 milliós rekordmennyiségű.

  Not null constraint van mindkét mezőn, de default null be van állítva (5.6 verzió)
  A táblák innodb tárolómotort használnak

  Amikor nincs alerts_3 index használatban a query futási ideje 48sec.
  A force index(alerts_3) megadásával 1.65sec-re redukálódik a futási idő.
  Statisztikákat ma frissítettem közvetlen tesztelés előtt, azok aktuálisak.

  Miért nem használja a mysql a rendelkezésére álló indexet? Ott van és mikor kényszerítem, működik.

  Miután elkezdtem játszani a selecttel és kivettem a tábla oszlopát (vagy betettem az index-el rendelkező oszlopot) a select clause-ból így alakultunk át:

  mysql> explain SELECT a.eventid
-> FROM alerts a, events e
-> WHERE e.eventid=a.eventid;
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
| 1 | SIMPLE | a | index | alerts_3 | alerts_3 | 8 | NULL | 3723507 | Using index |
| 1 | SIMPLE | e | eq_ref | PRIMARY | PRIMARY | 8 | zabbix.a.eventid | 1 | Using index |
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
2 rows in set (0.00 sec)

  Hogy lehetne a forrás SQL átírása nélkül rábírni a mysql-t, hogy az a.eventid oszlopon is használja az indexet annak ellenére, hogy valóban a tábla minden sora candidate row és jó ötletnek tűnhet első körben felolvasni mindent a blokkokból?

  [ Szerkesztve ]

  -- end of transmission --

• #1986 SaNyEe aktív tag sonar #1985

  Új Válasz 2018-04-10 19:00:09 #1986

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SaNyEe

  aktív tag

  válasz sonar #1985 üzenetére

  Nem segitett, force index kellett, ugy lett 1.65s a futasi ido. Az alkalmazas forrasahoz nincs hozzaferesem, elegans modjat (db szintu) szeretnem valasztani a problema megoldasanak.

  Ehhez egy uj app release kene es az is csupan egy szepsegtapasz lenne

  Masik erdekesseg amibe botlottam es nagyon meglepett oracle utan A+B tabla inner joinnal letrehozott, mindket tabla oszlopait tartalmazo rendezett, limitalt lista letrehozasanak koltsege iszonyat magas volt. A tabla 4 millio, b tabla 4db rekordot tartalmazott.

  Az eredmeny eloallitasa kb 60 sec volt, ha csak a tabla oszlopait jelenittettem meg az kb instant megjelent. (1db where clause volt a tablara, indexelt)

  -- end of transmission --

• #1988 SaNyEe aktív tag martonx #1987

  Új Válasz 2018-04-11 08:00:37 #1988

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SaNyEe

  aktív tag

  válasz martonx #1987 üzenetére

  Már ne is haragudj, de a hozzászólásod szakmai szemmel egyszerűen értékelhetetlen, több szinten is.
  Ezért kár volt billentyűzetet ragadni, igazán.

  -- end of transmission --

• #1990 SaNyEe aktív tag martonx #1989

  Új Válasz 2018-04-11 08:50:23 #1990

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SaNyEe

  aktív tag

  válasz martonx #1989 üzenetére

  Már látom, hogy nem a megfelelő fórumhoz fordultam
  Enterprise üzemet nem bíznál rá? Hm, titoktartási szerződés miatt nem nyilatkozhatok, de meglepődnél mekkora vállalatok, milyen rendszerei futnak mysql felett Bár kinek mi a móricka szint az relatív

  (Attól, hogy valahogy konfigurálva van perpill az innodb engine s az optimájzer, nem jelenti azt, hogy más beállításokkal ne működne jobban, vagy épp optimálisan)
  Az Oracle-t is be tudom neked úgy állítani exadatán akár, hogy arcpirongatóan gyorsnak tűnjön mellette egy access "adatbázis"

  [ Szerkesztve ]

  -- end of transmission --

• #1992 SaNyEe aktív tag baracsi #1991

  Új Válasz 2018-04-11 09:13:07 #1992

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SaNyEe

  aktív tag

  válasz baracsi #1991 üzenetére

  Ami a számomra furcsa az optimizerben, hogy preferálja a komplett adathalomhoz való hozzáférést az adott where záradékban, mert olyan oszlopokat sorolok fel a select záradékban, amik végül a select statement eredményeként megjelen(het)nek.
  Nyilván ez sokkal-sokkal több szekvenciális és random IO-val jár, mintha csupán az indexekből táplálkozna, majd random hozzáférne a kiadni szükséges blokkokhoz (csupán egyszer egy adatblokkhoz), ahogy a példa jól mutatja is.

  MySQL ide vagy oda, biztos vagyok benne, hogy ez beállítási kérdés lesz Ekkora multinál, mint aminél felmerült a téma, egy release upgrade még sztem min 1 évet várat magára, addig maradnak a patchek max (:

  Megszakértetem a hivatalos supporttal is úgyamúgy, ha valami eredménye lesz azt majd megosztom, csak sokszor szakértői fórumokon néha jön gyorsabban is válasz.

  [ Szerkesztve ]

  -- end of transmission --

Új hozzászólás Aktív témák