Re: mysql slow query

2009-09-03 bef zés Gabor HALASZ
Kovács Attila írta: > Gabor HALASZ írta: > >> Nincs igazan ertelme. Minden message statusa new lesz, mivel eppen >> migralnam bele a maileket. Az elotte uldogelo smtp ugyis queueba rakja a >> >> > Az pont jó akkor > Tedd bele a feltételekbe, a query-d meg felgyorsul. > De pont n

Re: mysql slow query

2009-09-03 bef zés Kovács Attila
Gabor HALASZ írta: > Nincs igazan ertelme. Minden message statusa new lesz, mivel eppen > migralnam bele a maileket. Az elotte uldogelo smtp ugyis queueba rakja a > Az pont jó akkor Tedd bele a feltételekbe, a query-d meg felgyorsul. -- k-atti- __

Re: mysql slow query

2009-09-03 bef zés Gabor HALASZ
Kovács Attila wrote: > Gabor HALASZ írta: >> The DBMail internal status attribute is defined as follows: >> >> * >>MESSAGE_STATUS_NEW = 0 >> >> > Próbáld meg berakni plusz feltételként hogy a státusza 0. > Nincs igazan ertelme. Minden message statusa new lesz, mivel eppen mi

Re: mysql slow query

2009-09-02 bef zés Kovács Attila
Gabor HALASZ írta: > The DBMail internal status attribute is defined as follows: > > * >MESSAGE_STATUS_NEW = 0 > > Próbáld meg berakni plusz feltételként hogy a státusza 0. -- k-atti- _ linux lista - linux@mlf.linux.

Re: mysql slow query

2009-09-02 bef zés Gabor HALASZ
Kovács Attila wrote: >> > Attól még az index nem árt a dátumra, bár szerintem a dátumszűrés > helyett sokkal jobb lenne > a státusz mezővel játszani, amire van index, és a dbmail_messages-ben van. > Összeszorzod a messages-t meg a physmessage-t, és egyik oldalról szűrsz a > mailboxra (29), a má

Re: mysql slow query

2009-09-01 bef zés Kovács Attila
Gabor HALASZ írta: > Nem neztem vegig, amig nem ertem, minek. > > Nem is kell megfordítani, mert a mailbox_idnr -re van index, mint a mellékelt adattáblákból látszik. > Jo, majd lesz. > > Attól még az index nem árt a dátumra, bár szerintem a dátumszűrés helyett sokkal jobb lenne a státusz

Re: mysql slow query

2009-09-01 bef zés Gabor HALASZ
Kovács Attila wrote: > Gabor HALASZ írta: >> Akkor forditva lene ;) Amugy melyik elso kettore is gondolsz? Es miert >> lenne ez nekem jo? >> > Le is írtam oda neked fordítva :). Nem neztem vegig, amig nem ertem, minek. > Mert akkor nem kell full table scant nyomni a sql motornak, feltéve ha >

Re: mysql slow query

2009-09-01 bef zés Kovács Attila
Gabor HALASZ írta: > v.headervalue='' AND p.internal_date > NOW() - INTERVAL 3 DAY; > Hahh. Bele akartam kötni a now() függvényedbe, de ügyes ez a mysql. A select indítása és befejezése között végig ugyanazt az értéket adja. A sysdate viszont jól meglassítaná a selectedet ;). -- k-atti- _

Re: mysql slow query

2009-09-01 bef zés Kovács Attila
Gabor HALASZ írta: > Akkor forditva lene ;) Amugy melyik elso kettore is gondolsz? Es miert > lenne ez nekem jo? > Le is írtam oda neked fordítva :). Mert akkor nem kell full table scant nyomni a sql motornak, feltéve ha sikeresen tudsz szűrni (van index). Persze az is lehet hogy a m.mailbox

Re: mysql slow query

2009-09-01 bef zés Gabor HALASZ
Kovács Attila wrote: > Gabor HALASZ írta: >> SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON >> m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id >> JOIN dbmail_headername n ON v.headername_id=n.id WHERE m.mailbox_idnr=29 >> AND n.headername IN ('re

Re: mysql slow query

2009-09-01 bef zés Kovács Attila
Gabor HALASZ írta: > SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON > m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id > JOIN dbmail_headername n ON v.headername_id=n.id WHERE m.mailbox_idnr=29 > AND n.headername IN ('resent-message-id','message-i

Re: mysql slow query

2009-09-01 bef zés Gabor HALASZ
Miloska wrote: >>> 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 forras

Re: mysql slow query

2009-09-01 bef zés Miloska
>> 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 t

Re: mysql slow query

2009-09-01 bef zés Gabor HALASZ
Miloska wrote: >> Rows_examined: 307816 > >> ++-++++--+-++--++ >> | id | select_type || type || key | key_len || rows | >> ++-++++--+-++--++ >> | 1 | SIMPLE || r

Re: mysql slow query

2009-09-01 bef zés Miloska
> Rows_examined: 307816 > ++-++++--+-++--++ > | id | select_type || type   || key                  | key_len || rows | > ++-++++--+-++--++ > |  1 | SIMPLE      || range  || headername  

mysql slow query

2009-09-01 bef zés Gabor HALASZ
Van egy nagy halom slow-query-m: # Time: 090901 12:00:01 # u...@host: DBMail[DBMail] @ localhost [] # Query_time: 52.065513 Lock_time: 0.000205 Rows_sent: 0 Rows_examined: 307816 SET timestamp=1251799201; SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p