Začal semestr, začal i podzim a kromě hub rostou jako po dešti i veřejné dílny v Praze. Nedávno strahováci referovali o hackerspacu Bordel, nyní se otevřela dílna Dejvice Lab jen kousek od ČVUT. Na blížící Virtuální Bastlírně tak uslyšíte nejen report z návštěvy dílny HWLab, ale i řadu novinek, událostí a úsměvných momentů, které se za poslední měsíc ve světě techniky, ale i vědy udály. Připojte se tedy již v úterý 13.10. od 20:00 a zapojte se do
… více »Byl vydán LineageOS 24 (Mastodon). LineageOS (Wikipedie) je svobodný operační systém pro chytré telefony, tablety a set-top boxy založený na Androidu. Jedná se o nástupce CyanogenModu. LineageOS 24 je založený na Androidu 17.
Společnost Valve publikovala na svém GitLabu nákresy a schémata zapojení headsetu Steam Frame. Pro nekomerční účely.
Soutěž Pwn2Own Ireland 2026 skončila 9. října. Bezpečnostní výzkumníci získali celkem 1 262 000 dolarů na odměnách. Během soutěže bylo předvedeno zneužití 98 zero-day zranitelností. Testování zahrnovalo různé kategorie zařízení a software. Výzkumníci předváděli prakticky fungující útoky podle pravidel soutěže. Výsledky následně slouží výrobcům při přípravě oprav. Mezi pokořenými jsou: Samsung Galaxy S26, OpenAI Codex, Oracle Autonomous AI Database, Google Pixel 10, u iPhone 17 neuspěli.
Programovací jazyk Python byl vydán v nové verzi 3.15.0. Podrobný přehled novinek v aktualizované dokumentaci.
BIGWORDS.PAGE je open-source webová aplikace, která po otevření odkazu v prohlížeči vykreslí přes celou obrazovku jednoduché informační sdělení. Zpráva i její nastavení jsou uložené v části URL za znakem #, například odkaz https://bigwords.page/#abclinuxu zobrazí jako velký bílý nápis 'abclinuxu' na černém pozadí. Obsah odkazu lze upravovat i vestavěným editorem, ten umožňuje nastavovat formátování a vizuální efekty textu, časovače, QR kódy a obrázky. Zdrojový kód je dostupný pod licencí MIT na GitHubu.
V neděli 11. října proběhne rotace klíče kořenové zóny. Podruhé v historii. Ondřej Filip na blogu CZ.NIC: "Pokud je pro Vás DNS protokol spíše výzva, ale přesto spravujete nějakou síť či DNS resolver, zkuste si jednoduchý test, který připravila firma Cloudflare na této adrese. Obzvláště zbystřit byste měli, pokud uvidíte nějaká červená políčka."
Vláda Spojených států se rozhodla vyřadit americkou softwarovou společnost Microsoft a několik dalších velkých technologických podniků z programu, který umožňuje kvalifikovaným zahraničním pracovníkům získat povolení k trvalému pobytu. Oznámila to včera administrativa amerického prezidenta Donalda Trumpa. Opatření zdůvodnila rozsáhlým zneužíváním programu, který je dlouhodobě terčem kritiky ze strany Trumpových příznivců, neboť prý znevýhodňuje americké pracovníky.
Datové centrum největší ruské technologické společnosti Jandex v Rjazaňské oblasti se stalo cílem dronového útoku a zastavilo provoz. Jandexu se někdy přezdívá „ruský Google“. Provozuje nejoblíbenější internetový vyhledávač v Rusku nebo aplikace pro objednávky jídla a taxi. Využívají jej desítky milionů lidí v rusky mluvících zemích.
Francouzská společnost Mistral AI představila Mistral Large 4 (interně přezdívaný 'le Chonk', volně přeloženo 'pořádný macek'), 'open-weight multimodální hybridní instruct-and-reasoning model s architekturou granulárního MoE, nativně podporující více jak 160 jazyků'. Model má přes jeden bilión parametrů, z nichž při práci využívá 49 miliard, kontextové okno o délce milion tokenů a obrazový enkodér o 1,6 miliardách parametrů.
… více »nasledujici select funguje ale trva uzasnych 22 vterin
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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... :)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'?
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...
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
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ě).
Rovny si být mohou, otázka spíš je, zda jsou si ekvivalentní. 
Řekl bych, že celkově to nemá cenu příliš komentovat...
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
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"?
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.
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.
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.
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
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
Aha, a mám to samozřejmě špatně, místo IS NOT NULL tam patří IS NULL.
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
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.
'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).
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í
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...
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)=2006a
datum >= '2006-06-01' AND datum <= '2006-06-30'
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.
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.
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.
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
Tahle query trvá 2 vteřin
s/2/20/
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
EXPLAIN
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 nullPS: chci věšteckou kouli
... 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
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.
Tiskni
Sdílej:
