It reports zero, even though it shows the
index in the "show create table" result. It also doesn't speed up the query
at all and it actually performs worse if I FORCE INDEX mysql to use this
one.
Do you guys have any idea as to why creating this index might not be
working?
Just now realized I answered to Mike only oops.
So posting it again... forcing the use of the use_id index didn't really
improve things, unfortunately.
Cheers,
Leonardo Borges
www.leonardoborges.com
On Sat, Jul 9, 2011 at 7:24 AM, mos wrote:
> Leonardo,
>What happens w
Withers wrote:
> What did the explain output look like after the new index?
>
>
> On Fri, Jul 8, 2011 at 8:53 AM, Leonardo Borges <
> leonardoborges...@gmail.com> wrote:
>
>> Hi Johnny,
>>
>> I just gave that a try but it didn't help as I suspected.
&g
hey can then
be filtered by the WHERE clause.
This type of query seems to be a corner case in mysql one should be aware
about when working with large datasets.
Cheers,
Leonardo Borges
www.leonardoborges.com
On Fri, Jul 8, 2011 at 11:18 PM, Johnny Withers wrote:
> Leonardo,
>
> I think a new
|
++-+---+---+-+--+-+++-+
Cheers,
Leonardo Borges
www.leonardoborges.com
On Fri, Jul 8, 2011 at 11:58 AM, Johnny Withers wrote:
> Can you post show create table for activity and explain output of the
> problem query?
>
> On Jul 7, 2011 8:51 PM, "Leonardo Borges"
> wrote:
>
>
//this could
potentially bring the runtime down in the case of a larg temp table.
select count(u.id)
from users u
left outer join email_sent_100 s
on u.id = s.user_id
and s.user_id is null;
A lot more lines and a lot more complex, but does the job in this example.
I'd appreciate your thoughts.
Cheers,
Leonardo Borges
www.leonardoborges.com
