Ú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?

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