2. Fórumok
  3. Szoftverfejlesztés
  4. MySQL topic
Legfrissebb anyagok
Mobilarena témák
PROHARDVER! témák
IT café témák
GAMEPOD témák
Keresés

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

  • #1992 SaNyEe aktív tag baracsi #1991
    Új Válasz #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.

  • #1990 SaNyEe aktív tag martonx #1989
    Új Válasz #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 :U 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" :))

  • #1988 SaNyEe aktív tag martonx #1987
    Új Válasz #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.

  • #1986 SaNyEe aktív tag sonar #1985
    Új Válasz #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)

  • #1984 SaNyEe aktív tag
    Új Válasz #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?

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

Hirdetés