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 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 3
dnes 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
dnes 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
dnes 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 25
dnes 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
dnes 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
dnes 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

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

Opera 44, verze 44.0.2510.857, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 57. Z novinek vývojáři Opery zdůrazňují podporou Touch Baru na nejnovějších MacBoocích Pro (gif). Přehled novinek pro vývojáře na blogu Dev.Opera.

Ladislav Hagara | Komentářů: 1
včera 20:56 | Pozvánky

V úterý 28. dubna se koná další Prague Containers Meetup. Přijďte si zopakovat, jak psát kvalitnější Dockerfile a jaké novinky a ulehčení přináší ansible-container, který vám umožní spravovat celý životní cyklus vašeho kontejneru. Místo konání: Concur, Bucharova 11, Praha-Stodůlky.

little-drunk-jesus | Komentářů: 0
včera 17:00 | Nová verze

Po půl roce od vydání verze 3.22 bylo vydáno GNOME ve verzi 3.24 s kódovým názvem Portland. Vydání obsahuje 28 459 změn od přibližně 753 přispěvatelů. Z novinek lze zmínit funkci noční světlo, přepracovaná nastavení, aplikaci Recepty, zdokonalenou oblast pro upozornění nebo zdokonalený webový prohlížeč. Podrobnosti i s náhledy v poznámkách k vydání a v novinkách pro vývojáře a správce systémů.

Ladislav Hagara | Komentářů: 10
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 921 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Pomalý SELECT

    9.5.2009 18:24 Jirka
    Pomalý SELECT
    Přečteno: 629×

    Předem se omlouvám, za delší popis situace. Mám dvě tabulky, jedna je velká (milion záznamů) a druhá je číselník.
    Struktura tabulek:

    CREATE TABLE `tab` (
      `id` INT NOT NULL AUTO_INCREMENT,
      `login` char(1) NOT NULL,
      PRIMARY KEY (`id`),
      KEY `login` ( `login` )
    ) ENGINE=MyISAM;
    
    CREATE TABLE `user` (
      `login` char(1) NOT NULL,
      `name` varchar(30) NOT NULL,
      PRIMARY KEY ( `login` ) 
    ) ENGINE=MyISAM;
    

    Naplním daty číselník:

    INSERT INTO `user` (`login`, `name`) VALUES ('a', 'AAA');
    INSERT INTO `user` (`login`, `name`) VALUES ('b', 'BBB');
    INSERT INTO `user` (`login`, `name`) VALUES ('c', 'CCC');
    INSERT INTO `user` (`login`, `name`) VALUES ('d', 'DDD');
    INSERT INTO `user` (`login`, `name`) VALUES ('e', 'EEE');
    INSERT INTO `user` (`login`, `name`) VALUES ('f', 'FFF');
    INSERT INTO `user` (`login`, `name`) VALUES ('g', 'GGG');
    INSERT INTO `user` (`login`, `name`) VALUES ('h', 'HHH');
    INSERT INTO `user` (`login`, `name`) VALUES ('i', 'III');
    INSERT INTO `user` (`login`, `name`) VALUES ('j', 'JJJ');
    

    A pomocí PHP velkou tabulku náhodnými údaji:

    for ($i = 0; $i < 1000000; $i++)
         mysql_query("INSERT INTO `tab` (`login`) VALUES ('".chr(rand(97,106))."')");
    

    Nyní potřebuji provést následující dotaz:

    SELECT SQL_CALC_FOUND_ROWS `tab`.`id`, `tab`.`login`, `user`.`name` 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    ORDER BY `tab`.`id` DESC 
    LIMIT 1;
    +---------+-------+------+
    | id      | login | name |
    +---------+-------+------+
    | 1000000 | i     | III  | 
    +---------+-------+------+
    1 row in set (2.58 sec)
    

    Co mě vadí, je doba trvání dotazu. Pokud odstraním SQL_CALC_FOUND_ROWS, dotaz se zrychlí:

    SELECT `tab`.`id`, `tab`.`login`, `user`.`name` 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    ORDER BY `tab`.`id` DESC 
    LIMIT 1;
    +---------+-------+------+
    | id      | login | name |
    +---------+-------+------+
    | 1000000 | i     | III  | 
    +---------+-------+------+
    1 row in set (0.01 sec)
    

    Nebo když odstraním LEFT JOIN, dotaz se opět zrychlí:

    SELECT SQL_CALC_FOUND_ROWS `tab`.`id`, `tab`.`login` 
    FROM `tab` 
    ORDER BY `tab`.`id` DESC 
    LIMIT 1;
    +---------+-------+
    | id      | login |
    +---------+-------+
    | 1000000 | i     | 
    +---------+-------+
    1 row in set (0.32 sec)
    

    Kupodivu, když přidám WHERE, tak se dotaz také zrychlí:

    SELECT SQL_CALC_FOUND_ROWS `tab`.`id`, `tab`.`login`, `user`.`name` 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    WHERE `tab`.`login`='a' 
    ORDER BY `tab`.`id` DESC 
    LIMIT 1;
    +--------+-------+------+
    | id     | login | name |
    +--------+-------+------+
    | 999998 | a     | AAA  | 
    +--------+-------+------+
    1 row in set (0.17 sec)
    

    Jenže já bych potřeboval zrychlit ten první dotaz, ale nevím jak na to. Může mi někdo poradit, či vysvětlit proč dostávám tak rozdílné časy?

    Odpovědi

    9.5.2009 18:30 Jirka
    Rozbalit Rozbalit vše Re: Pomalý SELECT

    Ještě dodávám, že to testuji na openSUSE 11.1 a na  MySQL 5 z distribuce.

    9.5.2009 18:51 Vojtěch Horký | skóre: 39 | blog: Vojtův zápisník | Praha
    Rozbalit Rozbalit vše Re: Pomalý SELECT
    Nejde náhodou o to, že s tou klauzulí SQL_CALC_FOUND_ROWS server vykonává ten dotaz jako by tam nebyl ten LIMIT 1, aby zjistil, kolik bude řádků (tudíž bez toho WHERE to bude asi full-scan) a teprve pak to ořeže?

    Nevyšlo by rychleji ptát se na počet řádků pomocí dalšího COUNT(*) dotazu (to by měl stačit průchod přes index)?

    BTW - indexy máte vytvořené?
    I am always ready to learn although I do not always like to be taught. (W. Churchill)
    9.5.2009 19:02 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Pomalý SELECT
    Spojovat tabulky přes řetězce je, řekněme, suboptimální – daleko lépe se bude databázi pracovat, pokud v té tabulce vytvoříte číselný primární klíč a spojovat budete přes něj. Dotaz bez SQL_CALC_FOUND_ROWS je rychlejší, protože v tom druhém dotazu používáte LIMIT – s ním databázi stačí, když najde první výsledek, a ten vám vrátí. Když ale musí spočítat SQL_CALC_FOUND_ROWS, musí stejně dotaz provést celý, jako by tam LIMIT nebyl.
    10.5.2009 09:14 Jirka
    Rozbalit Rozbalit vše Re: Pomalý SELECT

    Díky za náměty a rady. Všechny jsem je postupně vyzkoušel a navíc jsem ještě zkusil změnit engine na InnoDB. Změna enginu zrychlila dotaz více jak dvakrát. Provést dotaz bez SQL_CALC_FOUND_ROWS a následně použít COUNT(*) opět zrychlilo dotaz dvakrát. Pokud jsem tabulky spojil přes TINYINT došlo je k malému zrychlení. Vítězem je tedy kombinace všech návrhů:

    CREATE TABLE `tab` (
      `id` INT NOT NULL AUTO_INCREMENT,
      `login` TINYINT NOT NULL,
      PRIMARY KEY (`id`),
      KEY `login` ( `login` )
    ) ENGINE=InnoDB;
    
    CREATE TABLE `user` (
      `login` TINYINT NOT NULL,
      `name` varchar(30) NOT NULL,
      PRIMARY KEY ( `login` ) 
    ) ENGINE=InnoDB;
    

    Naplnit daty

    SELECT `tab`.`id`, `tab`.`login`, `user`.`name` 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    ORDER BY `tab`.`id` DESC 
    LIMIT 1;
    +---------+-------+------+
    | id      | login | name |
    +---------+-------+------+
    | 1000000 |     5 | EEE  | 
    +---------+-------+------+
    1 row in set (0.00 sec)
    
    SELECT count(*) 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    ORDER BY `tab`.`id` DESC;
    +----------+
    | count(*) |
    +----------+
    |  1000000 | 
    +----------+
    1 row in set (0.49 sec)
    

    Což je pětinásobné zrychlení. Nevýhodou je u enginu InnoDB delší vkládání dat a absence fulltexty. Všem díky.

    AraxoN avatar 10.5.2009 18:25 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Pomalý SELECT

     

    SELECT count(*) 
    FROM `tab` 
    LEFT JOIN `user` ON `tab`.`login` = `user`.`login` 
    ORDER BY `tab`.`id` DESC;
    +----------+
    | count(*) |
    +----------+
    |  1000000 | 
    +----------+
    1 row in set (0.49 sec)
    

    Což je pětinásobné zrychlení. Nevýhodou je u enginu InnoDB delší vkládání dat a absence fulltexty. Všem díky.

    A ešte sa Ti to urýchli asi miliónkrát, keď odtiaľ vyhodíš ten zbytočný LEFT JOIN a ORDER BY: :-D

    SELECT count(*) 
    FROM `tab`;
    +----------+
    | count(*) |
    +----------+
    |  1000000 | 
    +----------+
    1 row in set (0.00 sec)
    
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    11.5.2009 08:51 Jirka
    Rozbalit Rozbalit vše Re: Pomalý SELECT

    Špatný nápad to není, on je dokonce skvělý. Celé je to ve třídě, která se stará o zobrazení jakéhokoli SQL dotazu v prohlížeči, ta třída se stará o stránkování. K tomu potřebuji znát i celkový počet řádků. Takže se ten SQL dotaz musí upravit programem. Zatím je postup následující:

    přidám k SQL dotazu LIMIT a provedu dotaz

    odstraním vše mezi SELECT a FROM a dám tam COUNT(*)

    A teď ještě vyhodit všechny LEFT JOIN a ORDER BY, ale nechat všechny WHERE, GROUP, HAVING. Nepopletl jsem to?

    AraxoN avatar 11.5.2009 14:05 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Pomalý SELECT

    Ak je ten SELECT vyrobený automaticky, tak to takto fungovať nebude... Teda pri tomto jednom by to fungovalo, ale nie je to univerzálne a ani to univerzálne byť nemôže.

    Niečo podobné na zobrazovanie listingov používame aj my (komponent, ktorý robí najprv SELECT ... LIMIT OFFSET, a potom z toho odvodí ešte SELECT COUNT), a riešime to tak, že ten druhý SELECT na zistenie počtu riadkov sa tam dá nanútiť, ak automaticky vyrobený SELECT nie je optimálny, alebo nefunguje správne.

    A fine is a tax for doing wrong. A tax is a fine for doing well.

    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.