Hi Jim,
On Tue, Dec 30, 2008 at 5:54 PM, Jim Lyons wrote:
> On Sat, Dec 27, 2008 at 12:38 PM, Jake Maul wrote:
>
>>
>> 3) Obviously it'd probably be faster if you weren't using
>> SQL_NO_CACHE... guessing you just did that to show us what it's like
>> that way?
>>
>>
> Why would SQL_NO_CACHE slo
On Sat, Dec 27, 2008 at 12:38 PM, Jake Maul wrote:
>
> 3) Obviously it'd probably be faster if you weren't using
> SQL_NO_CACHE... guessing you just did that to show us what it's like
> that way?
>
>
Why would SQL_NO_CACHE slow it down? By not checking the cache or storing
the resultset into cac
Mmm I just tested this and it does indeed work (although i tested with
slightly less rows :o) )
explain select count(*) , date_format(calldate, '%y-%m-%d') as m from
cdr_warehouse group by m \G
*** 1. row ***
id: 1
select_type: SIMPLE
Hi,
On Sat, Dec 27, 2008 at 6:15 PM, Chris Picton wrote:
> Hi
>
> I am trying to get to grips with understanding mysql performance.
>
> I have the following query:
>
> select sql_no_cache count(*), date_format(calldate, '%y-%m-%d') as m from
> cdr_warehouse group by m;
>
> This gives me:
> 115 ro
In the last episode (Dec 27), Chris Picton said:
> I am trying to get to grips with understanding mysql performance.
>
> I have the following query:
>
> select sql_no_cache count(*), date_format(calldate, '%y-%m-%d') as m from
> cdr_warehouse group by m;
>
> This gives me:
> 115 rows in set (59
I few random things come to mind...
1) Try the query with IGNORE INDEX calldate_idx ... I can't see how
this could possibly be faster, but I always like to check anyway. In
your case this should result in a full table scan, given the
information you've given us.
2) If the performance problem come
