Miloska wrote: >> Rows_examined: 307816 > >> +----+-------------++--------++----------------------+---------++------++ >> | id | select_type || type || key | key_len || rows | >> +----+-------------++--------++----------------------+---------++------++ >> | 1 | SIMPLE || range || headername | 302 || 2 | >> | 1 | SIMPLE || ref || headername_id | 8 || 2889 | >> | 1 | SIMPLE || eq_ref || PRIMARY | 8 || 1 | >> | 1 | SIMPLE || ref || physmessage_id_index | 8 || 1 | >> +----+-------------++--------++----------------------+---------++------++ >> >> Valami otlet, hogyan lehet reprodukalni/kideriteni? > > > Ugyan azon a DB-n nezted az explain-t ahol lassu vagy esetleg egy > masikon, pl slave-en? >
Egyelore single, tesztkornyezet. > InnoDB? lenyegebem, 5.1.36-xtradb > > Az en multkori problemam? > Hasonlo lehet, csak a nagy tomegu insertnel latom, es kozben a lekerdezesek gyorsak, ha a mar insertalt uzenetek nezem valami mail klienssel, akkor >1000message/s-el jonnnek a headerek, kozben az insert all. Viszont BTR_KEY nincs a forrasban, patkolni nem tudom. > 'Kezzel' futtatva is sokaig tart a query? Nem sajnos, akkor volna mit neznem. Csak a nagy rajzolgatasban lemaradt az utolso sor: 4 rows in set (0.20 sec), de inkabb 0.0x korul szokott lenni. Az rows valtozik, ha periodikusan futtatom ugyanazt az explain queryt, de mindig gyors, kiveve egyszer :( Ami feltuno meg, hogy az io a hegyekbe szokik (nem ez lesz a vegleges storage alatta, de azert ez kicsit sok, plane, hogy nfs-rol olvassa az olvasnivalot). Probaltam particionalni is, atirtam az adatbazist, hogy foreign keys helyett triggereket es stored proceduret hasznaljon, de nem lett jobb a dolog, akkor (nem egeszen varatlan modon :) a cpu lett a szuk keresztmetszet. -- Gabor HALASZ <[email protected]> _________________________________________________ linux lista - [email protected] http://mlf2.linux.rulez.org/mailman/listinfo/linux
