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í
×
dnes 11:00 | Komunita

Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už zítra 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.

xkucf03 | Komentářů: 0
včera 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 3
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

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

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 1
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
15.1. 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 8
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (74%)
 (3%)
 (10%)
Celkem 309 hlasů
 Komentářů: 24, poslední včera 10:14
    Rozcestník
    Reklama

    Dotaz: MySQL velký SELECT

    30.4.2008 15:22 Petr
    MySQL velký SELECT
    Přečteno: 1461×
    Dobrý den,

    když spustím tento dotaz, běží několik minut (pak jsem ho ukončil) a ostatní uživatele nemohou s databází vůbec pracovat:

    SELECT Records.ClientNr, Clients.Name AS Nazev, LEFT(Clients.VSB,2) AS Obch, COUNT(DISTINCT Records.RecordNr) AS Spisy, DATE_FORMAT(Recdate,'%Y%m') AS DatM, MAX(CASE WHEN VChrontable.Kuerzel = 'V23' THEN VChrontable.Datum END) AS DatSml, SUM(CASE WHEN Chrontable.Kuerzel LIKE 'RG%' AND Chrontable.Kuerzel <> 'RGKČX' OR Chrontable.Kuerzel LIKE 'Z00%' THEN Chrontable.Betrag ELSE 0 END) AS Suma From Records, Chrontable, Clients, VChrontable Where Records.RecordNr = Chrontable.RecordNr And Records.ClientNr = Clients.ClientNr And Clients.ClientNr = VChrontable.ClientNr GROUP BY Records.ClientNr, DatM

    Je špatně napsaný ten SELECT, nebo špatný hardware nebo nastavení MySQL? Recordset je otevřen na straně serveru. Verze MySQL 4.1.13, linux SUSE.

    tabulka Records má 65 000 záznamů, Chrontable 880 000, Clients 12 000, VChrontable 95 000 záznamů.

    Odpovědi

    Heron avatar 30.4.2008 15:27 Heron | skóre: 50 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Chtělo by to upravit formátování.

    Co na to řekne EXPLAIN? Používají se indexy nebo fullscan? Jaký je typ tabulek? Jaký je to HW? Tabulky jsou poměrně malé, neměl by být důvod pro takovéto časy.
    30.4.2008 16:07 Petr
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    typ tabulek je MyISAM. HW nevím, je to nějaký nový server.
    EXPLAIN:
    -------+-----+------+--------------+----------+-------+-----------------+-----+--------------+
    |select|table|type  |possible_keys |key       |key_len|ref              |rows |Extra         |
    -------+-----+------+--------------+----------+-------+-----------------+-----+--------------+
    |SIMPLE|Recor|ALL   |PRIMARY,CL_IDX|[NULL]    | [NULL]|[NULL]           |65621|Using filesort|
    |SIMPLE|Clien|eq_ref|PRIMARY       |PRIMARY   |      4|Records.ClientNr |    1|              |
    |SIMPLE|VChro|ref   |Client_idx    |Client_idx|      5|Clients.ClientNr |    7|Using where   |
    |SIMPLE|Chron|ref   |Record_idx    |Record_idx|      5|Records.RecordNr |   13|Using where   |
    +------+------------+--------------+----------+-------+-----------------+-----+--------------+
    30.4.2008 16:11 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    odporčam vám ísť na to postupne, najprv select jeden stĺpec, potom pridať ďaľší, až to jeden zblbne úplne (napr v poradí 1, 2, 3, 5, 4, 6, 7)
    30.4.2008 23:38 kafa | skóre: 10
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Nechybí vám v tabulce Records index na sloupci RecordNr, podle kterého spojujete?
    1.5.2008 10:51 Petr
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Nechybí. Všechny sloupce RecordNr a ClientNr jsou indexovány. Index je i na Chrontable.Kuerzel, Clients.Name, ale není na VChrontable.Kuerzel
    1.5.2008 18:49 kafa | skóre: 10
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Jo, už to vidím. Výběr z Chrontable ani Clients není nijak omezen, takže Records se musí číst celý. Problém ovšem vidím v tom, že v tabulce Records (evidentně M:N) se ClentNr bude mnohokrát opakovat a pro každý výskyt se musí znovu provést výběr podřízených řádků v tabulce Vchrontable. Já bych nejprve v jednom selectu vytvořil temporary tabulku ze spojení Clients a Vchrontable, (GROUP BY ClientsNr - víc než 12000 řádků by neměla) a pak bych Records spojoval pouze s Chrontable a touto temporary tabulkou). Jsem přesvědčen, že výsledek by byl mnohokrát rychleji.
    1.5.2008 20:52 kafa | skóre: 10
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Nebo ho alespoň přinutit, aby nezačínal spojení tabulkou M:N. Vyzkoušel bych SELECT STRAIGHT_JOIN ... a seznam tabulek za FROM seřadil v pořadí Clients, Vchrontable, Records, Chrontable. Pak se Vchrontable bude prohledávat pro každého použitého klienta pouze jednou.
    30.4.2008 15:59 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Trochu upravím formátování:
    SELECT
      Records.ClientNr,
      Clients.Name AS Nazev,
      LEFT(Clients.VSB,2) AS Obch,
      COUNT(DISTINCT Records.RecordNr) AS Spisy,
      DATE_FORMAT(Recdate,'%Y%m') AS DatM,
      MAX(CASE WHEN VChrontable.Kuerzel = 'V23' THEN VChrontable.Datum END) AS DatSml,
      SUM(CASE WHEN Chrontable.Kuerzel LIKE 'RG%' AND Chrontable.Kuerzel <> 'RGKČX'
        OR Chrontable.Kuerzel LIKE 'Z00%' THEN Chrontable.Betrag ELSE 0 END) AS Suma
    FROM
      Records,
      Chrontable,
      Clients,
      VChrontable
    WHERE
      Records.RecordNr = Chrontable.RecordNr
      AND Records.ClientNr = Clients.ClientNr
      AND Clients.ClientNr = VChrontable.ClientNr
    GROUP BY Records.ClientNr, DatM
    
    Jinak mi není jasné, co tím dotazem vlastně chcete zjistit. Ty podmínky v agregačních funkcích vypadají divně (proč nejsou ve WHERE?), používat za SELECTem mimo agregační funkce sloupce, které nejsou v GROUP BY, by vám v jiné databázi než MySQL neprošlo (a bez pohledu do dokumentace nedokážu určit, jak moc náhodně bude MySQL vybírat hodnoty pro ty sloupečky). Teď mne ještě praštilo do očí – pokud je DatM v GROUP BY opravdu ten formátovaný řetězec, pak chudák databáze – na to nemůže použít žádný index. A jestli se nepletu tohle by vám opět u jiných databází neprošlo.
    30.4.2008 16:06 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    ad DatM v group by: to by prešlo, alternatívne je možné písať group by 1, 5 (podľa prvého a piateho stĺpca)

    mne osobne sa nepáči:
    - spomínané chýbajúce stĺpce v group by
    - distinct v count
    - or v SUM - chýbajúce else v MAX

    podmienky v agregačných funkciách majú zmysel, aj keď podivný (návrh databázy smrdí nemčinou, tam sa podivnosti očakávať dajú)

    30.4.2008 16:30 Petr
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Pokusím se popsat tabulky :
    Records(RecordNr long,ClientNr long, Recdate date)
    Chrontable(Kuerzel varchar,Betrag double)
    Clients(ClientNr long, VSB varchar)
    VChrontable(ClientNr long, Kuerzel varchar, Datum date)
    
    a co chci zjistit:
    ClientNr, počet RecordNr, k nim součet RG (v mém dotazu AS Suma), první dva znaky z Clients.VSB,
    VChrontable.datum pro Kuerzel = 'V23' (pokud existuje) seskupeno podle ClientNr 
    a podle měsíce z Records.Recdate (yyyymm)
    
    nebo jinými slovy počet Records.RecordNr, 
    součet Chrontable.Betrag kde RecordNr=Records.RecordNr a kde Kuerzel LIKE 'RG%' ... za každý měsíc
     dle Records.Recdate a k tomu VChrontable.Datum kde je Kuerzel = 'V23' a k tomu Clients.VSB
    
    30.4.2008 17:03 Petr
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    když do WHERE přidám Records.ClientNr < 25, tak to proběhne za cca 20s a vrátí 140 řádků
    30.4.2008 20:46 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Co zase me prastilo do oci je spojeni tabulek. Nejsem si jisty, ale mam pocit, ze tebou pouzite spojeni spoji zaznamy kazdy s kazdym a teprve tohle spojeni filtruje podle where. Podle jmen sloupcu (a tvojeho where) odhaduji, ze by to mohlo byt
    FROM
      Records
      join Clients on Clients.ClientNr=Records.ClientNr
      join VChrontable on VChrontable.ClientNr=Records.ClientNr
      join Chrontable on Chrontable.Kuerzel=VChrontable.Kuerzel
    
    A urcite bych se pokusil vyhnout spojeni pres varchar polozku.

    Pokud placam nesmysly, prosim zkusenejsi, aby me opravili :-)

    Dejv
    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    30.4.2008 21:14 ZAH | skóre: 41 | blog: ZAH
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Skoro bych se připojil osobně bych zkusil subselecty. (Doufám že nekecám a MySQL to umí)
    SELECT
      Records.ClientNr,
      select Clients.Name from clients where Records.ClientNr = Clients.ClientNr AS Nazev,
      LEFT(Clients.VSB,2) AS Obch,
      select ....
      DATE_FORMAT(Recdate,'%Y%m') AS DatM,
      select .... 
      select ........
    FROM  
         Records
    GROUP BY 
          Records.ClientNr, DatM
    
    1.5.2008 00:45 kafa | skóre: 10
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Mýlíte se, oba způsoby spojení se provádějí naprosto identicky. Jde jen o jiný formát zápisu, který oddělí spojovací podmínky od ostatních, aby byl přehlednější pro člověka a ten méně chyboval. Databázi je to jedno - oba styly vyhodnocuje shodně.
    1.5.2008 11:52 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Hm, ja to tusil, ze zase placam blbosti :-D Diky za opravu :-)

    Dejv
    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    1.5.2008 12:03 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Ale jeste jeden tip pridam. Nechybi ve spojeni tabulek (teda ve where) jeste pole Chrontable.Kuerzel=VChrontable.Kuerzel?

    Dejv
    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    1.5.2008 12:12 Petr
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Ne. Tyto tabulky nemaji byt navzajem propojeny.
    1.5.2008 14:12 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    A jo, blbne jsem se dival, promin. V popisu tabulek nemas uvedeny sloupec Chrontable.RecordNr a ja si nevsiml, ze to podle neho mas spojene ve where.

    Priste zkusim lip cist :-D

    Dejv
    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    1.5.2008 15:52 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    "Ty podmínky v agregačních funkcích vypadají divně (proč nejsou ve WHERE?), používat za SELECTem mimo agregační funkce sloupce, které nejsou v GROUP BY, by vám v jiné databázi než MySQL neprošlo"
    MySQL něco takového opravdu sežere a ani nepípne? Není to "poněkud" proti SQL normě?
    1.5.2008 16:00 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    Jo. Něco podobného se mi kdysi povedlo s InterBase 6, když jsem to pak chtěl pustit na Firebirdu, tak na mne křičel :-) Ale už si nepamatuju přesně, o co šlo.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    1.5.2008 17:16 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    No když seskupuješ, tak musíš sloupce výsledku buď agregovat, nebo bez agregací používat sloupce s hodnotama, který jsou pro každý agregovaný řádek prokazatelně jednoznačný...třeba právě ty hodnoty, podle kterých se seskupuje. ;-) (Možná že v SQL normě jsou jen ty agregovaný sloupce a sloupce z GROUP BY, možná má databáze povolený inferovat další jednoznačný buňky - tím už si nejsem jistej.)

    Což Ti asi vysvětlovat nemusím, ale jsem si skoro jistý, že se Ti stalo právě tohle - taky se mi občas stane, že na to zapomenu, ale nikdy by mě nenapadlo, že může existovat ("relační", zde v uvozovkách ;-)) databáze, která na to neupozorní. BTW, pokud náhodou skutečně potřebuješ skupinu hodnot čistě do výsledku, ve Firebirdu 2.1 přibyla agregační fce LIST( [ {ALL | DISTINCT } ] <value_expression> [ ',' <delimiter_value> ] ), která umí "atomizovat" sloupce do seznamu prezentovatelného uživateli. Vrací to řetězec. Asi záleží na klientské straně, ale chvílema se to může hodit, třeba v ISQL.
    30.4.2008 20:38 cronin | skóre: 48
    Rozbalit Rozbalit vše Re: MySQL velký SELECT
    1.5.2008 18:43 Tomas
    Rozbalit Rozbalit vše Re: MySQL velký SELECT

    Formátování by opravdu hodně pomohlo na čitelnosti.

    Zkusil bych následující kroky ke zjištění co dělá problém:

    • Vyhodit COUNT( DISTINCT ...)
    • Vyhodit agregace a vyzkoušet jak dlouho poběží samotné joiny a zda se vrátí přibližně správný počet záznamů.
    • Ve frázi GROUP BY místo DatM dát RecDate a vyhodit ze selectu sloupec DatM

    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.