> ryc> <snip>
> Heikki> Well, mystery solved :). Except that why MySQL uses hours to
> Heikki> sieve away the extraneous rows in the first query.
> >>
> >> To be able to answer the question why:
> >>
> >> SELECT COUNT(*) FROM table1 WHERE col1=0 and col2=0
> >>
> >> Is slow, I would need to get an EXPLAIN for this query.
>
> mysql> explain select count(*) from messages where clean=0 and
> ryc> parentmsgid=0;
>
> ryc>
+----------+-------+---------------+-------------+---------+------+---------
> ryc> +-------------------------+
> ryc> | table | type | possible_keys | key | key_len | ref |
rows
> ryc> | Extra |
> ryc>
+----------+-------+---------------+-------------+---------+------+---------
> ryc> +-------------------------+
> ryc> | messages | index | parentmsgid | parentmsgid | 5 | NULL |
7207120
> ryc> | where used; Using index |
> ryc>
+----------+-------+---------------+-------------+---------+------+---------
> ryc> +-------------------------+
>
> How many rows satisfies the query? Is it about 7207120 rows ?
>
> Heikki, could it be that InnoDB will read the original row through the
> primary key even if MySQL has marked that it would be happy if InnoDB
> only returned the found keys from the secondary index ?
>
A total of 5 rows match this query.
ryan
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
