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 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ářů: 0
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ářů: 3
včera 11:55 | Humor

Majitelé koček by měli být obezřetní při používání desktopového prostředí XFCE ve výchozím nastavení. Používání XFCE může mást jejich kočky a vést k poškrábání displeje. Jedná se o chybu 12117. K dispozici je již patch.

Ladislav Hagara | Komentářů: 18
21.3. 15:55 | Nová verze

Byla vydána verze 7.5 sady aplikací pro SSH komunikaci OpenSSH. Jedná se o opravné vydání. Volba UsePrivilegeSeparation v sshd_config se stala zastaralou (deprecated). Upozornit lze na změnu formátu log záznamů. Novou verzi OpenSSH již nelze přeložit s upstreamem nepodporovanými verzemi OpenSSL.

Ladislav Hagara | Komentářů: 0
21.3. 14:44 | Nová verze

Byla vydána verze 5.1.0 svobodného integrovaného vývojového prostředí KDevelop. Z novinek lze zdůraznit podporu LLDB. Programátoři mohou nově ladit své programy pomocí GDB nebo LLDB MI. Jedná se o jeden z výsledků Google Summer of Code (GSoC 2016). Zdrojové kódy lze nově přímo z menu KDevelopu analyzovat pomocí nástroje Cppcheck. Přibyla podpora OpenCL. Vylepšena byla podpora programovacího jazyka Python. Přímo z menu lze měnit barevná schémata KDevelopu.

Ladislav Hagara | Komentářů: 6
21.3. 08:33 | Komunita

Emulátor terminálu Terminix byl s verzí 1.5.4 přejmenován na Tilix. Název Terminix se nelíbil společnosti Terminix, jež má registrovanou ochrannou známku Terminix. Společnost Terminix se zabývá hubením škůdců. Emulátor terminálu Tilix je naprogramován v programovacím jazyce D a využívá GtkD, což je rozšíření ke knihovně GTK+ pro D.

Ladislav Hagara | Komentářů: 7
20.3. 17:55 | Zajímavý software

Bill Zissimopoulos vydal po 16 měsících vývoje WinFsp ve verzi 2017. Jedná se o Windows File System Proxy aneb FUSE pro Windows. Díky WinFsp a SSHFS-Win si i uživatelé Windows mohou připojit vzdálené souborové systémy prostřednictvím šifrovaného spojení SSH (SSHFS). Zdrojové kódy WinFsp jsou k dispozici na GitHubu pod licencí GPLv3 [reddit].

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

    Dotaz: Mysql optimalizace tabulek nepomaha, stale velka zatez

    30.1.2008 15:19 Keli | skóre: 5
    Mysql optimalizace tabulek nepomaha, stale velka zatez
    Přečteno: 3147×
    Zdravim,

    chtel bych se zeptat popr. poradit ohledne databaze Mysql. Provozuji web server bezici na php 4 + mysql 4.2.1. V spickach (cca 50 queries/s) me stoupa load az k hodnotam 3, tabulky jsou optimalizovany pomoci indexu, dotazy provereny pres Explain. Cacheovani dotazu nemuze byt, protoze se data neustale meni.

    Muze byt problemem, to ze nejvice ctena + zapisovana tabulka ma cca 350000 zaznamu. Celkova velikost databaze je cca 100MB.

    Server Intel(R) Xeon(TM) CPU 2.80GHz, 1GB pameti, system Gentoo.

    Diky.

    Odpovědi

    30.1.2008 15:27 tyctor | skóre: 13
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    to asi nebude databazou, nieje nijak zvlast velka...
    kouzer avatar 30.1.2008 15:31 kouzer | skóre: 11 | Mladá Boleslav
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Ta db není moc velká.. Mám zkušenosti s daleko většíma.. Co se hodit třeba Create table??? Nebo taky třeba dotazy jaký tam běhaj... Tohle nikomu nic moc neřekne.
    Linux user #448944.
    30.1.2008 15:53 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Prikladam datovou strukturu nejvetsich tabulek photos 23000 zaznamu, photos_comments 356000zaznamu, ostatni tabulky maji maximalne 2 tisice zaznamu, nemyslim si, ze by nejak zasadne ovlivnovali vykon.
    CREATE TABLE `photos` (
      `id` int(8) NOT NULL auto_increment,
      `titulek` varchar(50) character set latin2 default NULL,
      `popis` text character set latin2,
      `vkladatel` varchar(50) character set latin2 default NULL,
      `vkladatel_email` varchar(50) character set latin2 default NULL,
      `kategorie` varchar(20) character set latin2 default NULL,
      `lokalita` varchar(50) character set latin2 default NULL,
      `jezdec` varchar(50) character set latin2 default NULL,
      `zobrazeno` int(8) default '0',
      `hodnoceno` int(5) default NULL,
      `hodnoceni` int(5) default NULL,
      `last_vote` varchar(20) character set latin2 default NULL,
      `ip` varchar(16) character set latin2 default NULL,
      `ins_time` datetime NOT NULL default '0000-00-00 00:00:00',
      `last_com_user` varchar(50) character set latin2 default NULL,
      `last_com_time` datetime default NULL,
      `category` int(2) default NULL,
      PRIMARY KEY  (`id`),
      KEY `hodnoceno` (`hodnoceno`),
      KEY `hodnoceni` (`hodnoceni`),
      KEY `vkladatel` (`vkladatel`),
      KEY `datum` (`datum`),
      KEY `ip` (`ip`),
      KEY `jezdec` (`jezdec`),
      KEY `ins_time` (`ins_time`),
      KEY `category` (`category`),
      KEY `lokalita` (`lokalita`)
    ) ENGINE=MyISAM;
    
    -- --------------------------------------------------------
    
    -- 
    -- Table structure for table `photos_comments`
    -- 
    
    CREATE TABLE `photos_comments` (
      `id` int(10) NOT NULL auto_increment,
      `photo_id` int(10) NOT NULL default '0',
      `jmeno` varchar(50) character set latin2 default NULL,
      `mail` varchar(50) character set latin2 default NULL,
      `comment` text character set latin2,
      `datum` varchar(20) character set latin2 default NULL,
      `ip` varchar(16) character set latin2 default NULL,
      `auth` int(8) default NULL,
      PRIMARY KEY  (`id`),
      KEY `photo_id` (`photo_id`)
    );
    Nejcastejsi dotazy na tabulky (spojovana tabulka photos_categories ma 12 zaznamu, id je primarni klic):
    SELECT photos.id AS id, titulek,datum,vkladatel, vkladatel_email,popis, lokalita,jezdec,zobrazeno,hodnoceno,hodnoceni,last_vote, photos_categories.category AS category, photos_categories.id AS cat_id FROM photos, photos_categories WHERE photos.category = photos_categories.id AND photos.id=36244 LIMIT 1
    
    SELECT id,titulek,hodnoceni/hodnoceno,hodnoceno FROM photos WHERE ins_time > CURRENT_TIMESTAMP - INTERVAL 7 DAY AND hodnoceno>10 ORDER BY (hodnoceni/hodnoceno) ASC LIMIT 10
    
    SELECT jmeno,mail,datum, comment,ip,id FROM photos_comments WHERE photo_id='33935' ORDER BY id
    Nikde nejsou zadne slozite dotazy, zadne spojovani x tabulek apod
    Dalibor Smolík avatar 30.1.2008 16:24 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Nevidím tam žádnou zradu ... snad jestli u tabulky photos není příliš mnoho klíčů (KEY), neposoudím, zda jsou bezpodmínečně nutné. Při zadávání id používám specifikaci
    id int unsigned not null auto_increment primary key
    ale to by nemělo mít na rychlost žádný vliv.
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    30.1.2008 16:29 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Indexu je tam mnoho kvuli vyhledavani, do tabulky photos neni az tak mnoho zapisu, zato naopak do tabulky photos_comments je zapisu velice mnoho, proto je tam index pouze jeden, ten pres ktery vyhledava seznam odpovidajicich komentaru.
    Dalibor Smolík avatar 30.1.2008 18:50 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    No, přesto bych počet indexů snížil. Já provádím vyhledávání přes skripty php, kdy vyhledávám všechny výrobky, které mají v názvu "polštář". Napíšu do formuláře třeba "polšt" a vyjede mi příslušná sestava ..
    Seznam a detaily faktur mám tvořený dvěma tabulkami, jedna je pro záhlaví faktury a druhá pro položky zboží. Ta druhá tabulka má 25 polí (sloupců), klíč mám jeden id auto_increment a další dvě pole mají indexy (pole pro číslo smlouvy a pro číslo faktury). Další indexy nepotřebuji.
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    30.1.2008 20:13 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    A kolik mate dotazu/s v spicce, pokud je jich minimum, je jedno zda-li mate indexy ci ne.
    Dalibor Smolík avatar 30.1.2008 20:46 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Dotazů je málo - max. 3 - 4 v jednom okamžiku. Otázkou je vyzkoušet rychlost, pokud je dotaz jenom jeden. V každém případě bez indexů bylo generování sestavy mnohem pomalejší.
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    30.1.2008 20:59 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Ano, to zajiste, bez indexu by to bylo pomalejsi. Nicmene u me je zatez nesrovnatelne vetsi nez u vas, dokud byla zatez mensi, zadne problemy s loadem nebyly.
    kouzer avatar 30.1.2008 17:32 kouzer | skóre: 11 | Mladá Boleslav
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Co zkusit "optimitze table" a "analyze table" ?
    Linux user #448944.
    30.1.2008 17:43 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    samozrejme vyzkouseno, nic vyznamneho se nezmenilo.
    kouzer avatar 30.1.2008 18:36 kouzer | skóre: 11 | Mladá Boleslav
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Nejsem expert, ale příliš indexů škodí.. Osobně bych hledal chybu někde v tom.. Třeba to rozdělit do víc tabulek.
    Linux user #448944.
    30.1.2008 20:12 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Indexy ovlivnuji vyhledavani tim ze jej zrychluji, naopak cim vic indexu, tim jde vykon dolu u update, insert, replace apod, kde se musi indexy po uprave dat prepsat.
    30.1.2008 20:42 Sinuhet | skóre: 31
    Rozbalit Rozbalit vše Re: Jaderné noviny - 12. 12. 2007

    Jste si jist, ze za to vytizeni muze mysql? Nejcastejsi dotazy jeste nemuseji byt ty, ktere davaji db nejvice zabrat. Jste si jist, ze prave v techto sql travi server nejvice casu?

    A zkuste sem vlozit explain tech selectu.

    30.1.2008 21:04 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Jaderné noviny - 12. 12. 2007
    Dle topu, je nejvetsi zatizeni CPU ma mysqld
    explain SELECT photos.id AS id, titulek,datum,vkladatel, vkladatel_email,popis, lokalita,jezdec,zobrazeno,hodnoceno,hodnoceni,last_vote, photos_categories.category AS category, photos_categories.id AS cat_id FROM photos, photos_categories WHERE photos.category = photos_categories.id AND photos.id=36244 LIMIT 1
        -> ;
    +----+-------------+-------------------+-------+------------------+---------+---------+-------+------+-------+
    | id | select_type | table             | type  | possible_keys    | key     | key_len | ref   | rows | Extra |
    +----+-------------+-------------------+-------+------------------+---------+---------+-------+------+-------+
    |  1 | SIMPLE      | photos            | const | PRIMARY,category | PRIMARY |       4 | const |    1 |       |
    |  1 | SIMPLE      | photos_categories | const | PRIMARY          | PRIMARY |       4 | const |    1 |       |
    +----+-------------+-------------------+-------+------------------+---------+---------+-------+------+-------+
    2 rows in set (0.02 sec)
    
    explain SELECT id,titulek,hodnoceni/hodnoceno,hodnoceno FROM photos WHERE ins_time > CURRENT_TIMESTAMP - INTERVAL 7 DAY AND hodnoceno>10 ORDER BY (hodnoceni/hodnoceno) ASC LIMIT 10
        -> ;
    +----+-------------+--------+-------+--------------------+----------+---------+------+------+-----------------------------+
    | id | select_type | table  | type  | possible_keys      | key      | key_len | ref  | rows | Extra                       |
    +----+-------------+--------+-------+--------------------+----------+---------+------+------+-----------------------------+
    |  1 | SIMPLE      | photos | range | hodnoceno,ins_time | ins_time |       8 | NULL |  446 | Using where; Using filesort |
    +----+-------------+--------+-------+--------------------+----------+---------+------+------+-----------------------------+
    
    mysql> explain SELECT jmeno,mail,datum, comment,ip,id FROM photos_comments WHERE photo_id='33935' ORDER BY id;
    +----+-------------+-----------------+------+---------------+----------+---------+-------+------+-----------------------------+
    | id | select_type | table           | type | possible_keys | key      | key_len | ref   | rows | Extra                       |
    +----+-------------+-----------------+------+---------------+----------+---------+-------+------+-----------------------------+
    |  1 | SIMPLE      | photos_comments | ref  | photo_id      | photo_id |       4 | const |    1 | Using where; Using filesort |
    +----+-------------+-----------------+------+---------------+----------+---------+-------+------+-----------------------------+
    
    
    31.1.2008 10:25 DRSON
    Rozbalit Rozbalit vše Re: Jaderné noviny - 12. 12. 2007
    a) "WHERE ins_time > CURRENT_TIMESTAMP - INTERVAL 7 DAY" tohle je smrt. Opravdu potrebujes fotky 7 dni zpatky s presnosti jakou ma CURRENT_TIMESTAMP ? Nestacilo by od pulnoci minuleho ctvrtka? Spocitej si v phpku nebo v cem to mas timestamp pulnoci 7 dni zpatky a porovnavej to jako cisla. Pak budes celej den spoustet ten samej dotaz a SQL cache ti k necemu bude.

    b) spust na vsech tabulkach ANALYZE TABLE a OPTIMIZE TABLE a spoustej to pravidelne (1 za tyden/den?). Po velkym mnozstvi insertu to dela zazraky.

    c) razeni podle pocitany hodnoty taky neni nic moc. Je to sice trosku proti normalizaci ale co si udelat novou tabulku s photo_id a vypocitanym hodnoceni/hodnoceno, nebo to rvat primo do photos a udrzovat to aktualni pri zmenach? Pak se na to da totiz udelat index :) Normalizace tim sice vazne utrpi, ale zrychleni to asi prinese.

    A posledni rada na zaver: Precti si toto http://me.in-berlin.de/doc/mysql-doc/manual_MySQL_Optimization.html Je to moc zajimavy cteni :)

    Dej pak vedet jak jsi dopadl, pripadne jestli jsi prisel na neco dalsiho. Resime ted podobnej problem (i kdyz to nemame tak kriticky ;)).
    30.1.2008 21:43 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    A load 3 ve špičce je moc? Přijde mi to OK. Spíše je otázkou, zda je dostačující rychlost odpovědi.
    30.1.2008 21:45 denix
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    V nasej aplikacii sice pouzivame Postgresql ale tiez sme mali velky problem so slabou vykonostou, potom som zmenil ext3 na raiserfs a vykon siel rapidne hore. Aky suborovy system pouzivate vy?
    31.1.2008 09:35 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Pouzivam ext3, je to ostry stroj nemuzu menit souborovy system :(
    31.1.2008 10:21 Duff
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Možná se u te ext3 podívat na nastavení commit (případně jaká je defaultní hodnota, při vytváření v gentoo) a pokud je nastavena na nějakou nízkou hodnotu (dost degraduje výkon, ale je bezpečná při výpadku), tak ji zvýšit (stačí na to remount fs). Někde ve faq je návod na optimalizac fs.
    31.1.2008 10:39 R
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    To je zbytocne.
    31.1.2008 08:19 razor | skóre: 32
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Zdar, ještě by si mohl uvést konfiguraci mysql. Např: show variables like '%size%'. A zapnout si logování pomalých dotazů, abys viděl na čem ti to visí (pokud to ovšem vázne na mysql).
    31.1.2008 09:32 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    mysql> show variables like '%size%';
    +---------------------------------+----------------------+
    | Variable_name                   | Value                |
    +---------------------------------+----------------------+
    | binlog_cache_size               | 32768                |
    | bulk_insert_buffer_size         | 8388608              |
    | delayed_queue_size              | 1000                 |
    | innodb_additional_mem_pool_size | 2097152              |
    | innodb_buffer_pool_size         | 16777216             |
    | innodb_log_buffer_size          | 8388608              |
    | innodb_log_file_size            | 5242880              |
    | join_buffer_size                | 131072               |
    | key_buffer_size                 | 134217728            |
    | key_cache_block_size            | 1024                 |
    | max_binlog_cache_size           | 18446744073709551615 |
    | max_binlog_size                 | 1073741824           |
    | max_heap_table_size             | 16777216             |
    | max_join_size                   | 18446744073709551615 |
    | max_relay_log_size              | 0                    |
    | myisam_data_pointer_size        | 4                    |
    | myisam_max_extra_sort_file_size | 2147483648           |
    | myisam_max_sort_file_size       | 9223372036854775807  |
    | myisam_sort_buffer_size         | 16777216             |
    | preload_buffer_size             | 32768                |
    | query_alloc_block_size          | 8192                 |
    | query_cache_size                | 0                    |
    | query_prealloc_size             | 8192                 |
    | range_alloc_block_size          | 2048                 |
    | read_buffer_size                | 2093056              |
    | read_rnd_buffer_size            | 2093056              |
    | sort_buffer_size                | 4194296              |
    | thread_cache_size               | 0                    |
    | tmp_table_size                  | 33554432             |
    | transaction_alloc_block_size    | 8192                 |
    | transaction_prealloc_size       | 4096                 |
    +---------------------------------+----------------------+
    31 rows in set (0.03 sec)
    
    Logovani pomalych dotazu mam zapnute a nic se neloguje, citac pomalych dotazu hlasi 0
    31.1.2008 08:58 R
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    Load 3 je uplne v pohode, ak je to stale rychle. Ta tabulka a databaza je malicka. Na webserveri (Celeron 1,7GHz, 1280MB RAM) mame 2GB databaz, dve tabulky maju >400MB (jedna z nich je najpouzivanejsia), pocet riadkov v niektorych tabulkach je okolo 2 milionov. Priemerne 65 queries/s. V spicke byva load aj 13 a napriek tomu je odozva velmi slusna.
    31.1.2008 09:30 Keli | skóre: 5
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    U me je prave odezva pomalejsi, jinak bych na to, ze je zvyseny load neprisel.
    31.1.2008 10:40 R
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    A este som zabudol: je tam ext3.
    2.2.2008 10:08 Jirka
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    A s jakymi parametry je pripojen disk? Treba parametr sync dokaze hodne zpomalit pristup na disk.
    15.2.2008 18:28 gondo
    Rozbalit Rozbalit vše Re: Mysql optimalizace tabulek nepomaha, stale velka zatez
    zdravim doporucujem vzhliadnut toto video http://video.google.com/videoplay?docid=2524524540025172110 niekde ku koncu je spomeute aj to ako optimalizovat ten vyber podla casu

    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.