abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:30 | Komunita

Bylo oznámeno, že bude proveden bezpečnostní audit zdrojových kódů open source softwaru pro implementaci virtuálních privátních sítí OpenVPN. Audit provede Matthew D. Green (blog), uznávaný kryptolog a profesor na Univerzitě Johnse Hopkinse. Auditována bude verze 2.4 (aktuálně RC 1, stabilní verze je 2.3.14). Audit bude financován společností Private Internet Access [reddit].

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
dnes 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 1
včera 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
včera 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 5
7.12. 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
7.12. 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 2
7.12. 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 10
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 27
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 803 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Pomalý SELECT

17.12.2009 19:45 dusan456 | skóre: 12 | Poprad
Pomalý SELECT
Přečteno: 798×
Zdravím,

mám problém s rýchlosťou tohto dotazu:
SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda 
FROM tab1 A, tab2 B, tab3 C 
WHERE A.top_id = '8930440' AND A.id=B.id AND A.id=C.id AND B.popistyp_id=11 
AND (B.language='sk' OR B.language='en') 
GROUP BY A.id
ORDER BY B.language='sk' DESC
A.id, B.id a C.id je index,

taktiež A.top_id je index,

B.language je index a

A.top_id je index.

B.popis typ je text.

B.popistyp_id nie je index, keďže mohutnosť je len 12, ale skúsil som dať aj index, no výsledok je rovnaký.

tab2 má okolo 3 mil. záznamov

Vykonanie dotazu trvá prvý krát niekoľko sekúnd, potom už ide rýchlo, čiže druhý, tretí atď to už nabehne okamžite. Ak ho však zadám po polhodine, zase prvý krát to trvá veľmi dlho, potom to už ide rýchlo.

Neviete prosím poradiť, ako by som to mohol zrýchliť?

A čo je vlastne príčinou toho, že prvý krát to ide pomaly a potom už rýchlo?

Vopred ďakujem za info.

Odpovědi

AraxoN avatar 17.12.2009 20:09 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pomalý SELECT
Skús EXPLAIN SELECT ... - to by Ti malo napovedať, či sa naozaj používajú indexy tam kde sa majú, alebo či ich treba vytvoriť / zmeniť / analyzovať (príkaz ANALYZE). Takto od pása by som ale tipoval, že pri prvom selecte sa to načítava z disku, preto to trvá dlhšie. Pri ďalších selectoch to potom už je v cache a ide to rádovo rýchlejšie. Ak sa to chvíľu nepoužíva, tak cache sa naplní inými vecami a zase sa to spomalí. Pomôže pridať do stroja viac RAM, ale ak sa jedná o naozaj veľkú databázu, tak potom už len optimalizovať aplikáciu.
A fine is a tax for doing wrong. A tax is a fine for doing well.
17.12.2009 20:27 dusan456 | skóre: 12 | Poprad
Rozbalit Rozbalit vše Re: Pomalý SELECT
Ďakujem za info, dal som EXPAILN SELECT a dostal som tento výpis:
id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra
1 	SIMPLE 	         A 	ref 	top_id, id 	top_id 	4 	       const 	636 	Using temporary; Using filesort
1 	SIMPLE 	         C 	ref 	id 	        id 	4 	    test.A._id 	  1 	 
1 	SIMPLE 	         B 	ref 	id,language 	id 	4 	    test.A._id 	 35 	Using where
Takže v A tabulke mám použiť spoločný index pre top_id a id?

Ja používam index pre top_id a id na každé samostatne.
AraxoN avatar 17.12.2009 21:41 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pomalý SELECT
Skús taký index vytvoriť a cez EXPLAIN pozrieť, či ho potom použije. Ak ho nepoužije, tak ho opäť zhodíš - nemáš čo stratiť...
A fine is a tax for doing wrong. A tax is a fine for doing well.
18.12.2009 00:06 vlasta | skóre: 10 | Brno
Rozbalit Rozbalit vše Re: Pomalý SELECT
ohledne te rychlosti, jeste muze byt problem v tom razeni, paklize ten dotaz vraci tisice radku, tak nejvic zdrzuje tohle. Zkus, jak to rychle dobehne bez toho razeni... Dalsi vec, co jsem nepochopil, je ten group by... K cemu to tam vlastne je a nezarve pritom interpret, ze se nejedna o group by vyraz?
hikikomori82 avatar 17.12.2009 21:41 hikikomori82 | skóre: 18 | blog: foobar | Košice
Rozbalit Rozbalit vše Re: Pomalý SELECT
OR je problem. ak je tam, v podstate nemoze pouzit index. Skus to rozdelit unionom. Navyse, ake je rozlozenie v stlpci b.language? (select b.language, count(*) from b group by 1), ak je tam tych jazykov malo (2,3) tak taky index je nanic a aj tak pojde sekvencne. '8930440' je string? Ak nie pis to bez uvodzoviek.
17.12.2009 22:56 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
Jen poznámečka:
Pokud by se jednalo o MySQL, tak jsem měl zkušenost, že dotazy zapisované tímto způsobem (spojování tabulek přes WHERE) na velkých datech (statisíce až miliony řádku v několika tabulkách) bylo docela o dost pomalejší než použití klausule JOIN a potvrdilo se to i na M$SQL(už ale nevím verzi) i když tam byl rozdíl výrazně nižší.
Vysvětlil jsem si to tak, že při zápisu přes WHERE se vytvoří data na vše a pak se omezují a při JOINování dochází k postupné redukci dat, tudíž to nemá takové paměťové nároky.
A na Oracle (jen z konzultace, nezkoušel jsem to) je to prej jedno.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
17.12.2009 23:01 dusan456 | skóre: 12 | Poprad
Rozbalit Rozbalit vše Re: Pomalý SELECT
..a nepomohol by ste mi prosim prerobiť to na JOIN dotaz? Ja som to stále nepochopil tie JOIN dotazy, ako to vlastne funguje.
17.12.2009 23:33 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
Zkusil jsem to - nějak se mně to nezdá a skoro spím :(
Pokud bych se na to měl podívat vážně, tak mně sem hoďte strukturu těch tabulek, potřeboval bych vědět kde jsou PRIMARNI a UNIQUE klíče a zítra během dopoledne se na to juknu (poctivě)
SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda
  FROM tab3 AS C
    LEFT JOIN tab1 AS A ON A.id=C.id AND A.top_id = '8930440'
    LEFT JOIN tab2 AS B ON B.id=C.id AND B.popistyp_id=11
      WHERE (B.language='sk' OR B.language='en')
      GROUP BY A.id
        ORDER BY B.language='sk' DESC
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
17.12.2009 23:39 vlasta | skóre: 10 | Brno
Rozbalit Rozbalit vše Re: Pomalý SELECT
myslim, ze pouziti left joinu muze rapidne zmenit mnozinu vracenych radku... Nehlede na to, ze outer joiny jsou obecne pomalejsi...
18.12.2009 00:00 dusan456 | skóre: 12 | Poprad
Rozbalit Rozbalit vše Re: Pomalý SELECT
Pripájam štruktúru tabuliek a vopred ďakujem za Vašu ochotu.

Ešte som tu aj čítal, že InnoDB je rýchlejšia, ako MYISAM, možno aj to by pomohlo??
CREATE TABLE `tab3` (
  `id` int(16) NOT NULL default '0',
  `url` varchar(255) default NULL,
  KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `tab2` (
  `popis` text,
  `popistyp_id` int(6) NOT NULL default '0',
  `id` int(16) NOT NULL default '0',
  `language` char(2) default NULL,
  KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `tab1` (
  `adresa` varchar(255) default NULL,
  `top_id` int(16) NOT NULL default '0',
  `trieda` char(2) default NULL,
  `id` int(16) NOT NULL default '0',
  `name` varchar(255) default NULL,
  KEY `top_id` (`top_id`),
  KEY `id` (`id`),
  KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
18.12.2009 11:06 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
Tak s touto strukturou, je asi JOIN vs. WHERE putna, bo je to opravdu každý s každým :), čekal jsem tam nějaké UNIQUE či PRIMARY
Můj předchozí pokus s LEFT JOIN je špatně.

PS: to ORDER BY, má být opravdu na pravdivostní hodnotu ?, dal bych tam jen ORDER BY B.language DESC nebo ORDER BY B.language ASC

Takže asi takto:

SELECT DISTINCT A.name, A.id, B.popis, C.url, A.adresa, A.trieda
  FROM (SELECT * FROM tab1 WHERE top_id = '8930440') AS A
       INNER JOIN tab2 AS B ON A.id = B.id AND B.popistyp_id =11 AND B.language IN ('sk', 'en')
       INNER JOIN tab3 AS C ON A.id = C.id 
  ORDER BY B.language DESC
Čekal bych vyšší výkon ale nevím (no a pak ještě doladit indexi podle EXPLAIN).
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
18.12.2009 11:36 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
Ještě možná by pomohl jeden DISTINCT navíc.
SELECT DISTINCT A.name, A.id, B.popis, C.url, A.adresa, A.trieda
  FROM (SELECT DISTINCT name, id, adresa, trieda FROM tab1 WHERE top_id = '8930440') AS A
       INNER JOIN tab2 AS B ON A.id = B.id AND B.popistyp_id =11 AND B.language IN ('sk', 'en')
       INNER JOIN tab3 AS C ON A.id = C.id 
  ORDER BY B.language DESC
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
18.12.2009 14:28 vlasta | skóre: 10 | Brno
Rozbalit Rozbalit vše Re: Pomalý SELECT
Za predpokladu, ze id je v tab1 primarni klic, tak ten distinct ve vnitrnim selectu je naprosto zcestny, niceho tim nedosahnes, krom zpomaleni dotazu, coz je trosku v rozporu se zadanim.

A za hypotetickeho predpokladu, ze vazba mezi tabulkami 123 je 1:1, tak je k nicemu i ten prvni distinct.

A take nemuzu zapomenout na jeden dalsi fakt, ze MySQL pri pouziti nested selectu jaksi opomiji pouzit pri relaci index...
18.12.2009 14:44 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
"Za predpokladu, ze id je v tab1 primarni ani unique klic" NIC není primární klíč :).
A tím pádem vnitřní distinct omezuje množinu již na počátku.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
18.12.2009 14:51 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
Sorry, repete:
"Za predpokladu, ze id je v tab1 primarni klic"NIC není primární klíč :).
A tím pádem vnitřní distinct omezuje množinu již na počátku.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
17.12.2009 23:37 vlasta | skóre: 10 | Brno
Rozbalit Rozbalit vše Re: Pomalý SELECT
poradil bych ti, at si koupis nejakou sql book for busy developers...
SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda 
FROM tab1 A
JOIN tab2 B ON B.id = A.id
JOIN tab3 C ON C.id = A.id
WHERE A.top_id = 8930440 
AND B.popistyp_id=11 
--AND (B.language='sk' OR B.language='en') 
--hezci a jednoduseji modifikovatelna je podle me klauzule in
AND B.language IN ('sk', 'en')
GROUP BY A.id
ORDER BY B.language='sk' DESC
Jestli je klauzule join rychlejsi nez spojeni omezene v klauzuli where se rika, ze by to melo byt vykonove stejne (resp. parser by to mel chapat jako stejny vyraz) a jestli ne, tak se jedna o bug. Nicmene joiny jsou pro spoustu lidi prehlednejsi a v pripade jejich pouziti te syntakticka kontrola nepusti pres opomenute vyjadreni relace...
18.12.2009 11:19 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pomalý SELECT
S prohlášením, že se jedná o bug bych byl opatrný, to že výsledek je identický ještě neznamená, že vnitřní optimalizace nemůže postupovat jinak.
Ale pravděpodobně u INNER JOIN to tak bude. S provádením LEFT a RIGHT JOINU, už to ale bude jinak (nehledě na to že LEF a RIGHT mohou mít na některých enginech rozdílný výkon).

Pozn. na PostrgeSql, jsem četl, že rychlost přes WHERE a JOIN je za ideálních podmínek identická, což už samo o sobě vzbuzuje oprávněnou pochybnost a nutí to aspoň zkusit (bohužel to teď nemohu najít, abych dal odkaz).

To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
okbob avatar 18.12.2009 11:36 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Pomalý SELECT
Rychlost spojení zapsaného skreze WHERE a INNER JOINu musí být identická v každém případě (v PostgreSQL). Ideální podmínky jsou, s prominutím, blbost.
okbob avatar 18.12.2009 08:11 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Pomalý SELECT
18.12.2009 16:09 cronin | skóre: 48
Rozbalit Rozbalit vše Re: Pomalý SELECT
Bez blizsieho skumania si dovolim podotknut, ze zabijakom vykonnosti je casto ORDER BY nad neindexovanym stlpcom. Ako uz bolo zmienene vyssie, tento ORDER BY obsahujuci hodnotu je sam o sebe podozrivy.
18.12.2009 23:07 dusan456 | skóre: 12 | Poprad
Rozbalit Rozbalit vše Re: Pomalý SELECT
Ďakujem všetkým za info, zistil som, že časový problém robí
ORDER BY language
15 rows in set (11.39 sec), bez ORDER BY je to (0.39 sec)

Potrebujem to však nutne vyriešiť, aby najprv radilo vysledky s language='sk' a až potom výsledky s language='en'.

Rozmyšlam vytvoriť tab4 v podstate identickú s tab1 v počte riadkov so stĺpcami 'id' a 'sk', kde by bolo 'sk' buď 1, alebo 0, podľa toho či obsahuje language='sk' a potom dať ORDER BY tab4.sk, možno to bude radiť rýchlejšie.

19.12.2009 10:57 cronin | skóre: 48
Rozbalit Rozbalit vše Re: Pomalý SELECT
Nestaci urobit index nad language? Potom byt mozno vedela databaza sekvencne citat zaznamy z toho indexu, namiesto citania vsetkych a nasledneho triedenia. To je totiz uzitocny side-effect indexu, ze udaje v jeho listoch su zoradene. Takze ak treba ORDER BY, staci ist sekvencne podla indexu a testovat splnenie WHERE; vsetko sa ale da urobit streamovo. A ked sa k tomu pridaju selektivne indexy z PostgreSQL alebo FBI z Oracle, staci dobry index a netreba overovat ani to WHERE. :-)

Ak sa skutocne jedna iba o pevne dany pocet jazykov, nie je mozne to vyriesit "inziniersky"? T.j. spustit dva selecty za sebou, kazdy pre jeden jazyk, a resultsety si spojit az v aplikacii?
19.12.2009 21:32 kulik
Rozbalit Rozbalit vše Re: Pomalý SELECT
To by snad musel byt bug databaze, setrideni 15 zaznamu by z hlediska casu vubec nemelo byt pozorovatelne. Jak se lisi plany s order by a bez order by? Je mozne, ze se voli plan, ktery by byl efektivni az od treba desetitisicu vybranych zaznamu. Pokud ano, pak je potreba ho zmenit, jak se to udela v MySQL nevim, ale pocitam ze nejake hinty by tam mely byt k dispozici.
6.10.2010 16:47 vlasta | skóre: 10 | Brno
Rozbalit Rozbalit vše Re: Pomalý SELECT
Resenim by bylo rozdelit dotaz na 2 totozne s rozdilnym language a spojit je pomoci UNION
6.10.2010 20:28 jakub hajek
Rozbalit Rozbalit vše Re: Pomalý SELECT
Na to pozor, na to, ze databaze vrati nejdriv zaznamy z prvni casti unionu a pak z druhe, nemuzete spolehat. Dokonce IMHO neni zaruceno ani to, ze zaznamy z jednotlivych casti unionu prijdou pohromade. Neznam tedy mysql, ale napr. v oracle tomu tak je.
6.10.2010 20:45 jos
Rozbalit Rozbalit vše Re: Pomalý SELECT
bez ORDER BY asi žádná databáze negarantuje pořadí vrácených záznamů, takže pozor na všechny SELECTy

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.