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íží...
včera 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
včera 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ářů: 0
včera 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ářů: 1
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ářů: 26
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
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

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

Dotaz: mysql interni limity (haluz pri selectu)

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

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: 66 | 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: 66 | 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: 66 | 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: 66 | 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: 66 | 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: 66 | 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: 37 | Praha
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: 66 | 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: 66 | 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.