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 10:50 | Zajímavý software

Mozilla.cz informuje o dvou nových experimentálních funkcích v programu Firefox Test Pilot (zprávička). Snooze Tabs slouží k odkládání panelů na později. Pokud vám někdo pošle odkaz, ale vy nemáte čas si stránku hned přečíst, můžete si naplánovat otevření panelu na později. Stačí kliknout na tlačítko a vybrat, kdy chcete panel otevřít. Firefox panel schová a ve vybraný čas znovu otevře. Pulse umožňuje ohodnotit, jak dobře stránka funguje, např. jak rychle se ve Firefoxu načetla. Podle nasbíraných hodnocení pak bude Mozilla prohlížeč ladit.

Ladislav Hagara | Komentářů: 1
dnes 02:00 | IT novinky

V Barceloně probíhá veletrh Mobile World Congress 2017. Nokia na něm například představila (360° video na YouTube) novou Nokii 3310 (YouTube). BlackBerry představilo BlackBerry KEYone (YouTube) s QWERTY klávesnicí. LG představilo LG G6 (YouTube). Huawei HUAWEI P10 a P10 Plus. Samsung představil tablet Galaxy Tab S3.

Ladislav Hagara | Komentářů: 0
včera 14:00 | Nová verze

Komunita kolem Linuxu From Scratch (LFS) vydala Linux Linux From Scratch 8.0 a Linux From Scratch 8.0 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází především s Glibc 2.25 a GCC 6.3.0. Současně bylo oznámeno vydání verze 8.0 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.

Ladislav Hagara | Komentářů: 0
včera 11:11 | Nová verze

Byla vydána verze 0.10.0 webového prohlížeče qutebrowser (Wikipedie). Přehled novinek v příspěvku na blogu. Vývojáři qutebrowseru kladou důraz na ovladatelnost pomocí klávesnice a minimální GUI. Inspirovali se prohlížečem dwb a rozšířeními pro Firefox Vimperator a Pentadactyl. Prohlížeč qutebrowser je naprogramován v Pythonu a využívá PyQt5. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU GPL 3.

Ladislav Hagara | Komentářů: 21
25.2. 16:22 | Nová verze

Po pěti měsících od vydání Waylandu a Westonu 1.12.0 oznámil Bryce Harrington (Samsung) vydání Waylandu 1.13.0 a Westonu 2.0.0.

Ladislav Hagara | Komentářů: 3
24.2. 13:37 | Bezpečnostní upozornění

Společnost Cloudflare (Wikipedie) na svém blogu potvrdila bezpečnostní problém s její službou. V požadovaných odpovědích od reverzní proxy byla odesílána také data z neinicializované paměti. Útočník tak mohl získat cookies, autentizační tokeny, data posílaná přes HTTP POST a další citlivé informace. Jednalo se o chybu v parsování HTML. Zneužitelná byla od 22. září 2016 do 18. února 2017. Seznam webů, kterých se bezpečnostní problém potenciálně týká na GitHubu.

Ladislav Hagara | Komentářů: 1
24.2. 08:22 | Nová verze

Byla vydána první beta verze Ubuntu 17.04 s kódovým názvem Zesty Zapus. Ke stažení jsou obrazy Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio a Xubuntu. Dle plánu by Ubuntu 17.04 mělo vyjít 13. dubna 2017.

Ladislav Hagara | Komentářů: 56
23.2. 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 41
23.2. 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 15
23.2. 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 724 hlasů
 Komentářů: 68, poslední dnes 07:29
    Rozcestník

    Dotaz: MySQL nepoužije primírní klíč při použítí count

    9.3.2014 22:27 dvestezar
    MySQL nepoužije primírní klíč při použítí count
    Přečteno: 576×
    Mám tabulku se 7500 řádky kde je ID primární klíč, ale když použiji

    tak mi to hledá přes 1,5 sec a EXPLAIN vyhodí
    SELECT COUNT(id) FROM data
    id	select_type	table	type	possible_keys	key			key_len	ref	rows	Extra
    1	SIMPLE		data	index	NULL		jiny_boolean_key	1	NULL	74695	Using index
    
    SELECT COUNT(*) FROM data
    id	select_type	table	type	possible_keys	key			key_len	ref	rows	Extra
    1	SIMPLE		data	index	NULL		jiny_boolean_key	1	NULL	72276	Using index
    
    je to normální vlastnost ?

    Odpovědi

    10.3.2014 07:49 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Je to normální vlastnost. Hodnota v EXPLAIN není přesná a funkce COUNT(*) je drahá.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    10.3.2014 08:18 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    No, je pravdou, že toto bylo z klienta. Pokud testuji profilování v phpMyadmin(local připojení) tak mi vychází jiné časy(nejdelší odesílání kolem 32ms) i když ve web aplikaci to vypadá jinak.

    Mám chápat, že pro MySQL je výhodnější projet boolean klíč než integer? Pokud jde o mohutnost tak je jasné, že boolean bude mít vždy míň, ale u počítání záznamů by to mělo být jedno, stejně musí spočítat řádky, myslel jsem že index má nějaký svůj 'count'.

    Jak moc se dá věřit profilování? Existuje rychlejší zjištění počtu řádků?
    10.3.2014 12:18 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Nejvýhodnější je COUNT(*) vůbec nepoužívat, zejména pokud je tento údaj potřebný často. Výhodnější řešení se dá zvolit podle Use Case. Běžně k podobným účelům používám triggery, např. pokud potřebuji spočítat počet nepřečtených zpráv v profilu.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    10.3.2014 14:09 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    V tom případě by bylo lepší na triger insert, upd a delete uložit v pomocné tabulce výsledek pro požadovaná count ?

    jako

    select
      sum(if(nova,1,0)), /*nová*/
      sum(1), /*vše*/
      sum(if(stav=2),1,0) /*přečtená*/
    from data
    Takto by se mezi operacemi s tabulkou odlehčilo s počítáním. Je fakt, že po změně tabulky chce člověk většinou(uživatel vždy) vědět stav, takže by se stejně countovalo. V každém případě by toto asi ulehčilo tak jak tak. Ale zas takový dotaz proleze tabulku celou, i když jen jednou.
    10.3.2014 14:11 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    oprava
    select
      sum(nova,1,0), /*nová*/
      sum(1), /*vše*/
      sum(stav=2) /*přečtená*/
    from data
    10.3.2014 21:57 vepr
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    predpokladam, ze se tato optimalizace tyka jen innodb a ne myisam, coz by se hodilo uvest.

    druha vec je, ze explain obcas, i kdyz ne moc casto, pise nesmysly, neda se mu uplne vzdy verit.
    11.3.2014 11:45 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Ano jedná se innodb, ale když to tak vezmu tak zas je problém v tom že se jedná o počty na usera, což by ztratilo smysl.

    Je lepší volat 3 dotazy které by byly vázány na indexy nebo jeden totaz výše uvedený s omezením where?

    Na jednom dotazu ušetřím na inicializacích, ale ne každý by projížděl všechny řádky. Optimalizátor určí index pro dotaz ne pro agreg.funkce. To asi nejspíš jen analyzovat co se chová rychleji při provozu.

    To samé jak jsem zjistil že je výhodnější cpát in( stav in (1,2) ) místo or (stav=1 or stav=2). To mi zas třeba explain ukázalo, že mi používal kvůli tomuto jiný jednoduchý index než složený, který jsem chtěl.

    Prostě neexistuje aby při count indexovaného klíče neprojel celý rozsah, pokud jej vůbec použije. Žádný index.count prostě neexistuje takže smůla.
    10.3.2014 08:29 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Příloha:
    Ještě přikládám výsledek z profilování.

    Všiml jsem si že je tam řádek logging slow query i když je nastaveno na 5s

    v logu jsem našel akorát
    SELECT /*!40001 SQL_NO_CACHE */ * FROM `data`;
    Je to zápis tohoto dotazu nebo mi unikl nějaký divný dotaz tohoto zápisu?
    10.3.2014 08:38 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    1.5 sec nad 7500 řádky je nesmysl snad i na telefonu, píšeš opravdu rychlost dotazu?
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    10.3.2014 08:59 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Testoval jsem to u známýho přes EMS a tam to psalo "1 rows fetched (1,404 sec)"

    Teď jsem to testoval přes workbench a
    Time	Action	Message	Duration / Fetch
    3	1	08:49:32	select count(*) from data
     LIMIT 0, 1000	1 row(s) returned	0.062 sec / 0.000 sec
    3	2	08:49:48	select count(id) from data
     LIMIT 0, 1000	1 row(s) returned	0.047 sec / 0.000 sec
    3	3	08:50:07	select count(1) from data
     LIMIT 0, 1000	1 row(s) returned	0.047 sec / 0.000 sec
    3	4	08:50:34	select count(*) from data_pozn
     LIMIT 0, 1000	1 row(s) returned	0.421 sec / 0.000 sec
    data 7293

    data_pozn 386047

    Kámoš mi to testoval teď přes EMS(s i bez limitu) a opět kolem 1,4s. EMS se zdá kapánek brzda. Tzn. že mám věřit profilování v phpmyadmin, kde po součtu vychází cca stejné časy jak u workbench ?
    10.3.2014 10:09 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Nerozumím řeči tvého kmene, říkám, že dotaz na count(*)nad pár záznamy, prostě nemůže trvat sekundu, když si pustím tento dotaz jako první nad nepoužívanou DB:
    mysql> SELECT count(*) FROM generator_1m;
    +----------+
    | count(*) |
    +----------+
    |  1048576 |
    +----------+
    1 row in set (0.01 sec)
    
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    10.3.2014 10:20 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    OK a profilování z phpmyadmin můžu věřit?
    10.3.2014 11:18 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    To nevím, používám jej jen velmi zřídka ani nevím, že tuto možnost nabízí, ale co jiného by dělal než něco jako
    SET profiling = 1;
    a pak při zobrazení:
    SHOW PROFILES;
    či
    SHOW PROFILE;
    A pokud by nešlo věřit tomu, tak už není čemu…
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    10.3.2014 14:32 Tomáš
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count

    Všimněte si, že v obou případech se jede přes jeden a ten samý index. Tento index je nad typem boolean (null nejspíše není povoleno) a lze se oprávněně domnívat že boolean index bude menší než libovolný jiný index (například nad integer sloupcem). Proto správně optimizer vyhodnotil že pro count(<něco co není null>) bude nejlevnější právě tento index. Zkuste si dohledat velikosti indexů a uvidíte.

    @Kit: cena funkce count (stejně jako ostatních agregačních funkcí) závisí na velikosti zdrojové množiny a také na tom kolik máte cílových agregačních skupin daných frází GROUP BY. V tomto případě je počet skupin pouze jedna a cena je v zásadě rovna ceně operace "full index scan" indexu nad non null sloupci.

    Je nesmysl aby uvedený dotaz nad 7500 řádky trval 1,5 s. Buď máte extrémně zatížený stroj (ve smyslu IO operací), nebo extrémně pomalý disk (starý 20+ let), nebo jinou fatální chybu v konfiguraci ( virtualizace, konfigurace paměti, ...). Podělte velikost zjištěného boolean indexu rychlostí cca 10MB/s ( pomalejší disk asi nemáte ) a dostanete přibližný response time na který by jste se měl dostat. V popisovaném případě lze čekat odpověď do 10ms (=načtení cca 75kB dat). V případě zásahu do cache (=opakované dotazy) by pak měl být response time do 2ms (=zpoždění sítě).

    10.3.2014 14:48 Tomáš
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Oprava na špatného linku pro zjištění velikosti indexů. Správný link je zde
    11.3.2014 11:48 dvestezar
    Rozbalit Rozbalit vše Re: MySQL nepoužije primírní klíč při použítí count
    Bylo to v klientu(EMS) v kterém se testovalo. Jak jsem psal výše vzdáleně připojený myslworkbech mi ukázal 32ms, zhruba stejně jako phpmyadmin v profilování.

    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.