Forum » Programiranje » [MariaDB] Kako postavit index za hitrejše izvajanje query-ja?
[MariaDB] Kako postavit index za hitrejše izvajanje query-ja?
HotBurek ::
Dobro jutro.
Evo, fantje in dekline, nov dan nov izziv.
Tokrat me zanima, kako bi lahko pohitril izvajanje spodaj omenjenega query-ja? Predvidevam, da bi moral postavit "pravi" index na tabeli, ali več njih. Ne vem pa, katere stolpce naj ta index pokriva.
Query se trenutno izvaja po ~5 minut, kar je a bit tu mač. V tabeli je 30 miljonov vrstic.
Tole je DDL za generirat tabelo:
Tole pa je query, ki ga poganjam:
Še za info, kako se podatke vnaša v tabelo:
-----------------------------------------------
UPDATE
Čeprav, sedajle sem prišel na idejo, da bi mogoče lahko ob INSERT-u "počistil" stare recorde ven in tako zmanjšal ponavljajoče se key-e iz preteklosti. Ob predopostavki, da bo tako brisanje hitro.
Bom mogoče to prvo naredil, pa lahko potem celo SELECT malo prilagodim. Hm...
Evo, fantje in dekline, nov dan nov izziv.
Tokrat me zanima, kako bi lahko pohitril izvajanje spodaj omenjenega query-ja? Predvidevam, da bi moral postavit "pravi" index na tabeli, ali več njih. Ne vem pa, katere stolpce naj ta index pokriva.
Query se trenutno izvaja po ~5 minut, kar je a bit tu mač. V tabeli je 30 miljonov vrstic.
Tole je DDL za generirat tabelo:
CREATE TABLE `autocomplete_to_rebuild` ( `keyword` varchar(40) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL, `country_name_3166` varchar(2) NOT NULL, `datehour` int(11) NOT NULL, `datetime` datetime NOT NULL, `keyword_length` int(11) NOT NULL, `country_name_3166_length` int(11) NOT NULL, PRIMARY KEY (`keyword`,`country_name_3166`,`datehour`), KEY `autocomplete_to_rebuild_datehour_IDX` (`datehour`) USING BTREE, KEY `autocomplete_to_rebuild_country_name_3166_IDX` (`country_name_3166`) USING BTREE, KEY `autocomplete_to_rebuild_keyword_IDX` (`keyword`) USING BTREE, KEY `autocomplete_to_rebuild_datetime_IDX` (`datetime`) USING BTREE, KEY `autocomplete_to_rebuild_keyword_length_IDX` (`keyword_length`) USING BTREE, KEY `autocomplete_to_rebuild_country_name_3166_length_IDX` (`country_name_3166_length`) USING BTREE, KEY `autocomplete_to_rebuild_keyword_country_name_3166_IDX` (`keyword`,`country_name_3166`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
Tole pa je query, ki ga poganjam:
SELECT `keyword`, `country_name_3166`, MAX(`datehour`) AS 'datehour' FROM `autocomplete_to_rebuild` WHERE `datehour` <= 2024022218 GROUP BY `keyword`, `country_name_3166` ORDER BY `datetime` ASC, `keyword_length` DESC, `country_name_3166_length` DESC, `country_name_3166` ASC LIMIT 1;
Še za info, kako se podatke vnaša v tabelo:
# set date now SET @date_now = NOW(); # set date hour SET @datehour = CONCAT( YEAR(@date_now), LPAD(MONTH(@date_now), 2, 0), LPAD(DAY(@date_now), 2, 0), LPAD(HOUR(@date_now), 2, 0) ); # insert ignore into INSERT IGNORE INTO `autocomplete_to_rebuild` ( `keyword`, `country_name_3166`, `datehour`, `datetime`, `keyword_length`, `country_name_3166_length` ) VALUES ( p_keyword, p_countr_name_3166, @datehour, NOW(), CHAR_LENGTH(p_keyword), CHAR_LENGTH(country_name_3166) );
-----------------------------------------------
UPDATE
Čeprav, sedajle sem prišel na idejo, da bi mogoče lahko ob INSERT-u "počistil" stare recorde ven in tako zmanjšal ponavljajoče se key-e iz preteklosti. Ob predopostavki, da bo tako brisanje hitro.
Bom mogoče to prvo naredil, pa lahko potem celo SELECT malo prilagodim. Hm...
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Utk ::
Kandidati so datehour, ta je skoraj ziher, pa tisti stolpci v group by, morda tudi stolpci v sort by, če je še zmeraj ful teh zapisov ko jih filtriraš. Kaj točno se bo najbolj obneslo je odvisno od podatkov. Poskusiš in vidiš, v čem je problem, to bi naredil hitreje kot odprl temo.
To so res osnove...
To so res osnove...
Zgodovina sprememb…
- spremenil: Utk ()
markito ::
Čeprav, sedajle sem prišel na idejo, da bi mogoče lahko ob INSERT-u "počistil" stare recorde ven in tako zmanjšal ponavljajoče se key-e iz preteklosti. Ob predopostavki, da bo tako brisanje hitro.
Ne rabiš lahko samo narediš update če je ključ že v tabeli.
INSERT INTO ... ON DUPLICATE KEY UPDATE
HotBurek ::
U, pa res. Tole z "ON DUPLICATE KEY UPDATE" se mi zdi zelo gut, ker bi na tak način imel vedno po en "key", datum (in uro) pa bi ob vnosu poslajdal na trenutno vrednost (ob INSERT-u).
Mislim, da bom to probal.
Mislim, da bom to probal.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Zgodovina sprememb…
- spremenilo: HotBurek ()
FireSnake ::
Zelo gut! Kar daj poslajdat!
Da ti prej ni kapnilo, da imaš duplikate v bazi je malo čudno.
Kot je nekdo zgoraj omenil: osnove.
S tem, da zopet ni bila podana celotna informacija (glede na UPDATE informacijo).
Da ti prej ni kapnilo, da imaš duplikate v bazi je malo čudno.
Kot je nekdo zgoraj omenil: osnove.
S tem, da zopet ni bila podana celotna informacija (glede na UPDATE informacijo).
Poglej in se nasmej: vicmaher.si
Zgodovina sprememb…
- spremenilo: FireSnake ()
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Iskalnik produktov po spletnih trgovinahOddelek: Programiranje | 5122 (671) | HotBurek |
» | Kako pohitrit build-anje index za autocomplete?Oddelek: Programiranje | 1066 (598) | DamijanD |
» | T-2 in portiOddelek: Omrežja in internet | 5140 (2590) | gazibo |
» | portal ostal, baza slaOddelek: Izdelava spletišč | 1828 (1713) | bombacina |
» | MySQL združevanje tabel..Oddelek: Programiranje | 1711 (1526) | Nemenej |