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 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
včera 07:22 | Pozvánky

Konference InstallFest 2018 proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Spuštěno bylo CFP. Přihlásit přednášku nebo workshop lze do 18. ledna 2018.

Ladislav Hagara | Komentářů: 0
12.12. 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 6
12.12. 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 13
12.12. 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 12
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

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ů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 976 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Dotaz: mysql interni limity (haluz pri selectu)

    31.7.2006 12:56 Kumar
    mysql interni limity (haluz pri selectu)
    Přečteno: 234×

    nasledujici select funguje ale trva uzasnych 22 vterin

    SELECT count(idz) AS dluzniku FROM `zakaznici`
    WHERE datum_z<'2005-12-01' AND idz NOT IN
       (SELECT zakaznik FROM `platby_2006`
        WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06)
    

    takze db programator neco ve smyslu a trvani dotazu je <2 vteriny coz je uzasne :)

    $x=mysql_query("SELECT zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06");
    SELECT count(idz) AS dluzniku FROM `zakaznici` WHERE datum_z<'2005-12-01' AND idz NOT IN ($x);
    

    Vysledkem $x je seznam cosel 1,2,3,... a pokud jich je vic nez 999 tzn trba 1000 mysql hrde zahlasi 0 rows coz je naprosto dokonala pitomost.

    Takze dotaz zni kde se nastavuji tyhle limity??? v mysql ve verzi 5.0.18rc2 ten limit neni ve verzi 5.0.22 ano prosel jsem changelogy mezi verzema ale nic zvlastniho zdrojaky jsem nezkoumal... :)

    Odpovědi

    31.7.2006 13:03 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    takze db programator neco ve smyslu a trvani dotazu je <2 vteriny coz je uzasne

    Je to tím vedrem nebo ta věta není česky? :-)

    Mimochodem, co to, proboha, znamená 'zakaznik NOT LIKE -1'?

    31.7.2006 14:27 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    takze db programator NAPSAL neco ve smyslu a trvani dotazu je <2 vteriny coz je uzasne

    vypadlo slovo :) asi to vedro
    31.7.2006 14:46 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Dost bych se ohradil proti tomu, že autora onoho kódu označujete za "db programátora". To je, jako byste Petra Novotného nazval mistrem televizní zábavy...

    31.7.2006 13:13 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Co když to napíšete takto?
    select count(IDZ) as DLUZNIKU from ZAKAZNICI Z
      left join PLATBY_2006 P on P.ZAKAZNIK=Z.IDZ
        and DATUM_S>='2006-06-01' and DATUM_S<'2006-07-01'
      where Z.DATUM_Z<'2005-12-01' and P.IDZ is null
    
    31.7.2006 13:19 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Ten server, na kterém to spouštíte, asi nemá nožičky, že? Protože kdyby je měl, tak by vyběhl z racku a nakopal by vás do prdele.

    Zkuste třeba něco jako
    SELECT count(idz) AS dluzniku FROM zakaznici LEFT JOIN platby_2006 ON (idz=zakaznik) WHERE datum_z<'2005-12-01' AND DATE_FORMAT(datum_s,'%m')=06 AND zakaznik IS NOT NULL
    (o optimálnosti podmínky DATE_FORMAT(datum_s,'%m')=06 ani nemluvě).

    31.7.2006 13:26 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Mimo jiné mne na přístupu tazatele trochu irituje ten nevyslovený předpoklad, že "všechny datové typy jsou si rovny"…
    31.7.2006 13:41 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Rovny si být mohou, otázka spíš je, zda jsou si ekvivalentní. :-) Řekl bych, že celkově to nemá cenu příliš komentovat... :-)

    31.7.2006 13:57 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Zajímavé je, že s podobnými absurditami se setkávám výhradně u lidí odkojených MySQL. Jenže pak mi vždycky někdo začne vysvětlovat, že MySQL je naprosto skvělá databáze a za tohle zcela určitě nemůže…
    31.7.2006 14:42 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Ale ona za to MySQL opravdu nemůže :-) Z databázových systémů jsem rovněž odkojen MySQL (když teda nepočítám FoxBase a FoxPro) a s rozlišováním a korektním používáním datových typů kupodivu nemám problém. Ovšem ono to bude dáno tím, že se striktně typovými jazyky jsem pracoval už v dobách, kdy o MySQL nebylo ani slechu ani vidu - a zažité návyky si nehodlám nechat zkazit žádnými beztypovými nebo nedejbože autotypovými věcmi jako MySQL či PHP :-)

    31.7.2006 14:23 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    OMG vypadlo me tam slovo proto ten silenej cestin jen sem naznacil ze proste nejak z ty query vymlati > 1000 zaznamu a narve je do druhy query tolik k divne polozenemu dotazu. Ja jen nevim proc to jde udelat v 5.0.18 a nejde v 5.0.22. BTW ten kod jsem nepsal proto je server na svem miste a bravurne zvlada vse ostatni :)
    31.7.2006 14:29 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Promiňte, ale pokud nezačnete používat aspoň interpunkci (ocenil bych i diakritiku, ale to bych asi chtěl moc), těžko to po vás bude někdo luštit.
    31.7.2006 14:49 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Dole jsem zopakoval dotaz i pro vás doufám v nakopnutí správným směrem.
    31.7.2006 15:34 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    :-)
    Promiňte, ale pokud nezačnete používat aspoň interpunkci.
    vs
    Dole jsem zopakoval dotaz i pro vás doufám v nakopnutí správným směrem.
    A teď si vyber: "dole jsem zopakoval dotaz i pro vás, doufám v nakopnutí správným směrem" nebo "dole jsem zopakoval dotaz, i pro vás doufám v nakopnutí správným směrem"?
    31.7.2006 20:30 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Tak to je hukot, ja se celkem bavím :), jen mě přijde absurdní, že pořád nemám odpověď na svoji otázku, ale vždycky mě někdo zjebe za češtinu. (Ano napíšu si diktát sloh jen někdo řekněte co ti borci v tom mysql změnili :) asi použiju debugger a projdu zdrojáky protože kromě diskuze na téma udělej to jinak nebo máš to blbě česky vole si tady půlka lidí honí lofase nad tím jak sqelou (tohle slovo je speciálně pro ně) mají češtinu. :)

    K.
    31.7.2006 21:29 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Otázku jste pořádnou nenapsal žádnou, přesto jste zde dostal mnoho odpovědí, jak problém vyřešit. Ale pokud nechcete vědět, jak problém vyřešit, ale chcete špatnou odpověď na špatnou otázku, aneb jak se v problému pořádně patlat, máte ji mít:

    Ptáte se kde se nastavují tyhle limity. Nevím které tyhle máte na mysli, ale:
    • v dokumentaci jsou popsány konfigurační parametry serveru, ve stejné dokumentaci je uvedeno i jakým způsobem je možné konfiguraci serveru nastavit; MySQL už nějakou dobu nepoužívám, ale příslušné kapitoly jsem pro vás našel
    • klientský porgram je předpokládám nějaký proprietární, každopádně jste nenapsal, o jakého klienta se jedná – kde se nastavují limity kleinta vám tedy neporadím, mělo by to být zdokumentováno u klientské aplikace, případně by to měl vědět její programátor (a pokud programátor a váš "db programátor" je jedna a též osoba, dodávám, že i klientské knihovny mají nějaké limity, většinou je možné ty limity konfigurovat, a jaké ty limity jsou a jak se nastavují bude popsáno v dokumentaci té klientské knihovny)
    • pokud k databázi přistupujete přes TCP/IP, můžou mít dále vliv třeba limity na délku TCP/IP spojení – zatím co se MySQL pokouší provést ten hloupý dotaz, může dojít síťové vrstvě trpělivost a prohlásí příslušné TCP/IP spojení za přerušené
    • a dále existuje spousta dalších míst, kde jsou různé další limity, které se při takto zoufalém návrhu databáze a dotazu mohou projevit. Přeju příjemnou zábavu při jejich objevování…
    Myslím, že nejsem v této diskuzi sám, komu bylo ctí odpovídat na váš dotaz, který je samozřejmě – když už se na něco ptáte v diskuzním fóru – jasně a srozumitelně formulován; dokonce, i když jsme tímto dotazem poctěni, dbal jste i na jazyk alespoň do té míry, že lze rozeznat jednotlivé věty i to, jakou mají výpověď… Až zase budete mít nějaký podobný dotaz, třeba proč sakra tím blbým šroubovákem ten hřebík nejde zatlouct, budeme zde všichni rádi vymýšlet šroubovák na zatloukání hřebéků a nikdo si neodváží navrhnout vám kladivo.

    Pokud se podíváte po okolních diskuzích, zjistíte, že není zas tak výjimečné, že se někdo ptá na špatnou věc. Myslím, že tady lidé docela mají snahu vyložit mu, v čem je problém a na co by se měl ptát spíš. Ale jak vidíte, umíme na hloupé dotazy odpovídat i hloupě – ono to zase nezabralo tolik času najít tu dokumetaci k MySQL a v ní správnou kapitolu…
    31.7.2006 22:09 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Uznavam prehnal jsem to.

    Ale stejne porad nevim jak obejit limit na NOT IN (..), ktery ma 999 polozek.

    BTW tu dokumentaci jsem opravdu precetl a zkousel nastavovat ruzne limity na serveru.

    Klientem (obyc mysql v konzoli serveru - neladim tu aplikaci) to neni, je to chyba serveru, stejny klient a server verze 5.0.18 to funguje bezproblemu.

    31.7.2006 22:27 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Nejlepší je právě tento limit neobcházet a použít jinou techniku, zvláště pokud ten seznam má vzniknout jako výsledek nějakého selectu. Obecně platí, že pokud cítíte potřebu psát nějaká data přímo do SQL dotazu, měl byste to chápat jako zdvižený varovný prst, že je nejspíš něco špatně. Pokud kvůli těmto datům nabyde dotaz kilometrových rozměrů, mělo by to pro vás být jasné znamení, že tohle není správná cesta.
    31.7.2006 22:28 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Že by existoval limit na NOT IN (…) považuji za nepravděpodobné. Ale i kdybych to vyzkoušel na verzi 4.1.14, kterou tu mám, a tam ten limit nebyl, bude vám ta informace k ničemu.

    Nemá ten klient třeba nastaven nějaký maximální počet záznamů, bufferování apod.? Chová se to stejně i když klienta spustíte mysql --quick?

    Ten dotaz ale určitě jde přepsat na outer join, se kterým si databáze dokáže poradit daleko líp – např. Michal Kubeček zde jeden napsal.
    31.7.2006 22:31 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    man mysql (1) a vyhledejte si "1000". Pak zkuste najít něco podobného (to samé) pro vaši verzi MySQL…
    31.7.2006 22:35 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Já bych se tomu zase tak moc nedivil. Je potřeba si uvědomit, že parser musí ten dotaz určitým způsobem zpracovat a převést do jakési interní reprezentace, přičemž 'not in (...)' s 999 hodnotami je vlastně 1000 podmínek spojených pomocí and. Samozřejmě nevím nic o tom, jak ten parser u MySQL vypadá a jak vypadá jeho interní reprezentace dotazu, ale dokážu si představit, že to může být docela vážný problém.
    1.8.2006 08:06 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Doufám, že vnořené selecty nepřevádí na nevnořený select s vloženými hodnotami ani parser MySQl… I kdyby někde něco takového bylo, nebude to 1000, ale 256, 65536 nebo i 1024. Ale těch 1000 – to vypadá na hodnotu pro lidi, ti mají ten divný zvyk používat desítkovou soustavu :-)
    1.8.2006 11:31 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    hmm, preco potom innodb ma max pocet stlpcov 1000 a nie 1024 ?

    ja by som sa pri konstantach necudoval. okruhle cisla typu 64 su vlastne len isty typ prezitku, odlisenia sa, take cislo 314 by splnilo ucel rovnako :-)

    1.8.2006 12:07 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Výjimka potvrzující pravidlo ;-)
    31.7.2006 13:42 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Aha, a mám to samozřejmě špatně, místo IS NOT NULL tam patří IS NULL.

    31.7.2006 14:56 Tunop
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Dobrý den, mohu se zeptat co je tak špatného na DATE_FORMAT(datum_s,'%m')=06? Jediné co mě napadá je, že daná funkce nejspíše vrací string takže ta 06 by měla být spíše '06'. Do databází pronikám a rád se nechám poučit. Děkuji
    31.7.2006 15:02 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    to, ze je pouzita vo where. To znamena, ze musi byt vypocitana pre kazdy riadok. Pre databazu je ovela stravitelnejsie datum_s between '2006-06-01' and '2006-07-01'.

    nevraviac tom, ze existuje tabulka platby_2006, potom bude platby_2007, kde dany problem pravdepodobne ziska na zlozitosti, a tak dalej.

    31.7.2006 15:08 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Navíc, chápu-li to dobře, výsledkem DATE_FORMAT() bude řetězec, takže je nesmysl ho porovnávat s číslem. Navíc bych si ani nebyl moc jistý, jestli test "'06' = 6" bude splněn nebo ne (asi bude záležet na tom, kterým směrem se bude provádět ta implicitní konverze).
    31.7.2006 15:11 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Pro každý řádek tabulky se pole datum_s z typu DATETIME (nebo jiného podobného) explicitně přeformátovává na string, a ten se pak s něčím porovnává. Z hlediska výkonu je to naprosto zoufalé, protože pokud byste napsal podmínku datum_s>='2006-06-01' and datum_s<'2006-07-01', provede parser jednou na začátku dotazu konverzi těch literálů na DATETIME a query už pak nativně porovnává DATETIME typy, což je MNOOOOHEM rychlejší, nemluvě o tom, že inteligentní člověk (tváří v tvář takové podmínce) si na daný sloupec vytvoří index, a pak je ten dotaz MNOHOŘÁDOVĚ rychlejší.

    Funkční rozdíl je pravda v tom, že konstrukce s DATE_FORMATem vybere data z 6. měsíce libovolného roku, ta druhá konstrukce jen ze 6. měsíce 2006 - ale z kontextu je zjevné, že to nevadí.

    A pochopitelně se ten výsledek DATE_FORMAT musí porovnávat s "06" a nikoliv s 06. V červnu to sice funguje, ale konkrétně v srpnu a září to fungovat nebude - což si laskavý čtenář dovodí jako cvičení :-)

    31.7.2006 15:46 podlesh | skóre: 38 | Freiburg im Breisgau
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Také bych douplnil důležitý údaj: pro extrakci jednotlivých složek (jako třeba měsíc) existují speciální funkce, které jsou rozhodně efektivnější.
    31.7.2006 19:32 Tunop
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Děkuji za vysvětlení, přesto mě to nedalo a udělal jsem si primitivní test...

    vytvořil jsem tabulku (databáze MySQL 5.xxx)...

    CREATE TABLE `test`.`speed_test` ( `Id` int(11) NOT NULL auto_increment, `datum` datetime NOT NULL, `text` varchar(255) CHARACTER SET 'utf8' COLLATE 'utf8_czech_ci' NOT NULL, `cislo` int(11) NOT NULL DEFAULT '0', `dlouhy_text` mediumtext CHARACTER SET 'utf8' COLLATE 'utf8_czech_ci' NOT NULL, PRIMARY KEY (`Id`) ) ENGINE=MyISAM CHARACTER SET='utf8';

    vložil do ní přibližne milion náhodných záznamů kde datum bylo v rozmezí 1.1.2000 00:00:00 až 28.12.2010 23:59:59 (texty a čísla byly taktéž náhodné) a po té aplikoval následující dotazy...

    select count(id) from speed_test where DATE_FORMAT(datum,'%m')="06" AND DATE_FORMAT(datum,'%Y')="2006";

    01:04

    select count(id) from speed_test where datum>='2006-06-01 00:00:00' and datum<'2006-07-01 00:00:00';

    01:04

    select count(id) from speed_test where MONTH(datum)="06" AND YEAR(datum)="2006";

    01:04

    číslo pod dotazem vždy udává pruměrný čas z 5 průchodů

    No jak vidíte tak výsledky jsou naprosto totožné, takže by mě zajímalo jak je to možné. Pochopitelně z toho nelze příliš usuzovat (nejedné se o skutečnou databázi, nejde o skutečný provoz, na pozadí mě běžely další procesy apod.) ale i tak jsem čekal alespoň nejaký rozdíl...
    31.7.2006 20:01 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Na sloupečku, který se porovnává, není index. Takže databáze váš dotaz musí provádět tak, že projde všechny řádky a porovná je. Pomaleji už to opravdu nejde.

    No a pak nechápu, proč nutíte databázi MONTH(datum) a YEAR(datum) převádět na řetězec a pak porovnávat řetězce. Pokud chcete opravdu porovnávat výkon kvůli optimalizaci, porovnejte (samozřejmě s indexem) varianty
    MONTH(datum)=6 AND YEAR(datum)=2006
    
    a
    datum >= '2006-06-01' AND datum <= '2006-06-30'
    
    31.7.2006 23:05 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Výsledky jsou naprosto totožné proto, že (pokud jste to nezkoušel na nějaké 386 s 8MB paměti) po prvním dotazu z toho vašeho "banchmarku" se ocitla celá tabulka v paměti a optimalizačních hashích MySQL.

    To je všechno. Když se mé ženy zeptáte osmkrát po sobě na to samé, odpoví vám osmkrát stejně. Když se jí každý den zeptáte na to samé osm dní po sobě, odpoví vám každý den jinak, a ještě nad tím bude dlouho přemýšlet.

    I přesto jsem si jist, že moje žena je inteligentnější než MySQL.

    31.7.2006 23:28 Tunop
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Tak MySQL jsem pochopitelně mezi jednotlivými dotazy restartoval. Celá tabulka má přes 700MB... BTW: chcete snad říct že pokud se MySQL zeptám jednou špatně a ona mě odpoví až za dlouho tak když se jí poté zeptám znovu na to samé ale lépe tak mě odpoví za stejně dlouho kvůli tomu že si to někde nahashovala...no to mě moc logiku nedává
    31.7.2006 23:47 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    Přeháněl jsem. Problém je v tom, že jste se třemi různě pitomými způsoby ptal na to samé. O pár komentářů výš vám někdo doporučoval indexovat ten tázaný sloupec, to jste nezkusil. Co vám mám odpovědět? Já nehodlám soudit, který z těch tří vašich dotazů je míň idiotský (slovo jako "lepší" zde nelze použít) a je mi zcela fuk, jak dlouho trvají. Zkuste napsat OPTIMALIZOVANÝ dotaz, s použitím indexů, a porovnejte ho s těmi ostatními.

    Pak se můžeme bavit dál - ale srovnávat tři pičoviny a řešit, která z nich je míň hnusná, nezlobte se, to mě nebaví. V této diskuzi zaznělo hodně užitečných postřehů, přeberte si je. Já se nehodlám bavit o způsobech, jak se co nejlépe škrabat pravou nohou za levým uchem.

    1.8.2006 00:07 Tunop
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Ale vždyť já netvrdím že to nejsou pitomosti, jak jsem již ve svém prvním postu uvedl s databázemi se teprve seznamuji a přijde mě čtení této diskuse podnětnější než studování základních seriálů třeba na Živě... bohužel jsem se zde toho zatím příliš nedozvěděl, rozhodl jsem se rovnou nepřijmout Vaše vysvětlení ohledně porovnávání, které je uvedeno v zakládajícím dotazu a tak jsem provedl svůj naprosto primitivní test. Ačkoli z něj vyšlo že všechny metody jsou stejně pomalé (nebo snad rychlé?), tak okamžitě přijdete s tím že je to celé "píčovina" a že se to tak nedělá (přitom jedna z metod vychází přímo z Vašeho popisu).

    Z uvedeného mě tedy vyplívá, že databáze není bez zapnutého indexovaní schopná Vašim způsobem odpovědět rychleji než způsobem, který jste zavrhl jako naprostý nesmysl (ačkoli by to i bez toho indexování mělo být "MNOOOOHEM rychlejší").

    Pokud se snad ješte rozhodnete reagovat tak bych byl rád za nějaký profesionální postup, jak by jste daný problém řešil Vy, já jsem opravdu databázové pako a nechám si poradit, děkuji. :-)
    1.8.2006 08:03 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    ačkoli by to i bez toho indexování mělo být "MNOOOOHEM rychlejší"
    To tady nikdo netvrdil. Je to asi stejné tvrzení, jako "auto i bez motoru musí být mnohem rychlejší". Indexy u databáze nejsou "jen tak něco navíc", indexy jsou podstata databáze. Druhou podstatnou částí je optimalizátor dotazů (proto je tak důležité databázi správně sdělit, co vlastně chcete najít). A to je skoro vše, všechno ostatní už jsou takové třešničky na dortu.
    31.7.2006 14:47 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Na serveru se programátor snaží udělat v query (ponecháme stranou čistotu řešení atd.), v té query použije výčet NOT IN (1,2,...) pokud má seznam 1-999 položek je vše v naprostém pořádku. Pokud se snaží udělat request s více položkami než 1000 server vrátí 0, což je nesmysl. Otázka zní kde se nastavuje limit pro to query aby to šlo neomezeně.

    pseudo kód není to přesná kopie každopádně mě jde o to udělat tu query funkční pro více než 1000 položek

    Tahle query trvá 2 vteřin
    SELECT count(idz) AS dluzniku FROM `zakaznici`
    WHERE datum_z<'2005-12-01' AND idz NOT IN
       (SELECT zakaznik FROM `platby_2006`
        WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06)
    
    No a teď to co se snaží udělat programator
    $result=mysql_query("SELECT zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06");
    #...tady si to parsne z resultu do $x="1,1,2,3,4,5,6"
    #...
    SELECT count(idz) AS dluzniku FROM `zakaznici` WHERE datum_z<'2005-12-01' AND idz NOT IN ($x);
    
    no takže snad takto
    31.7.2006 14:48 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Tahle query trvá 2 vteřin
    s/2/20/
    31.7.2006 15:12 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    karteziansky sucin vam nieco vravi? in a not in su v podstate porovnavanie kazdy s kazdym. A rozdiel v pripade subselectu pripisujem roznym datovym strukturam, predpokladam, ze taku trivialnu chybu, ako spustanie subselectu pre kazdy testovany riadok by si ani v mysql nedovolili.

    mysql, pokial viem, nema ziadne limity, o ktorych by bolo treba pisat. Co sa tyka max dlzke prikazu, v davnych casoch 4.0 sa odporucalo zvacsit premennu net_buffer_length

    31.7.2006 14:54 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    My jsme to pochopili. Ale snažíme se vám vysvětlit, že dělat to takhle je hloupost. Protože za prvé zcela zbytečně taháte spousty dat ze serveru na klienta a zpátky, za druhé zbytečně přiděláváte parseru práci příliš komplikovaným dotazem a za třetí při tomto typu řešení dříve či později na limit narazíte, ať si ho zvednete jakkoli. Proto by bylo lepší, abyste zkusil místo subquery použít ten join, pak by s tím nemusel optimalizátor mít takové problémy.
    31.7.2006 15:00 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Ja jsem admin. Nepíšu to :), upřímě řečeno taky bych to přepsal JOINama, ale já jen chci vědět kde jsou ty limity :). Mě zajímají ty limity kde to je :). No asi napíšuu join kterej sem pastnu aby to mohlo být označeno jako "solved".
    31.7.2006 15:18 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    btw, doporucujem pozriet sa na prikaz EXPLAIN
    31.7.2006 16:14 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    No vyřešil jsem to tim, že jsem udělal tohle :)
    SELECT * from `zakaznici` z LEFT JOIN (select zakaznik FROM `platby_2006` WHERE zakaznik NOT LIKE -1 AND DATE_FORMAT(datum_s,'%m')=06 ) tmp_platby on z.idz = tmp_platby.zakaznik where zakaznik IS null
    
    PS: chci věšteckou kouli
    31.7.2006 16:16 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Pro hnidopichy ano tady je v selectu * a ne ty idz...
    31.7.2006 16:19 zabza | skóre: 52 | blog: Nad_sklenkou_cerveneho
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Hnidopichům spíš bude vadit:

    ... WHERE zakaznik NOT LIKE -1 ...

    a

    ...DATE_FORMAT(datum_s,'%m')=06 ...

    a tohle je mi taky značně podezřelé .... :-)

    ... ON z.idz = tmp_platby.zakaznik WHERE zakaznik IS NULL
    31.7.2006 20:24 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)

    no trik je v tom, ze se dela left join se subselectem o dost rychlejsi nez na cele table :))),

    trik dva je to, ze se skutecne vyberou ti kteri maji null, ale jsou soucasti toho joinu...

    podstata problemu tkvi v tom ze vysledek jestli zakaznik patri tam ci onam se zjisti az z toho joinu kteri je lepsi delat na mene datech protoze misto 40 s trva 0,2s coz je nezanedbatelny rozdil...

    a ted me bijte vypada to hnusne, ale je to rychle

    ten datum je blbje ulozen takze pracuju s tim co je

    NOT LIKE -1 je tam kvuli zhovadilosti, kterou me vysvetloval auto navrhu :) prej ze tam AAAANO mohlo bejt neco hezciho

    K.
    31.7.2006 16:23 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Je ten subselect nutný?
    31.7.2006 20:25 Kumar
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    ANO JE!
    31.7.2006 20:59 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Ne, není. Ale to už vám marně vysvětlujeme od rána…
    1.8.2006 00:08 LesTR | skóre: 17 | Plzeň
    Rozbalit Rozbalit vše Re: mysql interni limity (haluz pri selectu)
    Marne hledam jeden duvod proc. Treba mi pomuzete : )
    Save The World - http://www.worldcommunitygrid.org/ LesTR

    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.