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í
×

včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 1
včera 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
včera 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

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

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
22.10. 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 6
22.10. 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

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

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (0%)
 (1%)
 (75%)
 (12%)
Celkem 235 hlasů
 Komentářů: 8, poslední 22.10. 23:02
    Rozcestník

    Dotaz: Pomalý SELECT

    17.12.2009 19:45 dusan456 | skóre: 12 | Poprad
    Pomalý SELECT
    Přečteno: 802×
    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.