Janusz Krzysztofik wrote:
...
I am trying to optimize MySQL (3.23.49 from Debian stable) setup for
ASPseek application. I decided to try InnoDB in order to be able
to update tables while performing time consuming selects.
After converting all tables to InnoDB I noticed a big difference
in
Marc,
Thank you for your prompt answer.
I run EXPLAIN in both cases and got:
MyISAM (fast):
mysql explain select url_id from urlword where deleted=0 and status=200
and origin=1;
+-+--+---+--+-+--+--++
| table | type | possible_keys |
You are not using any indicies, because there aren't any that could be
used in this query.
Try adding an index on (status,deleted)
Janusz Krzysztofik wrote:
Marc,
Thank you for your prompt answer.
I run EXPLAIN in both cases and got:
MyISAM (fast):
mysql explain select url_id from urlword
Janusz,
Now the question is: how should I set up (and maintain?) my MySQL server
to prevent it
from using indexes inefficiently?
Quite a good question, no idea.
But if the query
select url_id from urlword where deleted=?? and status=??? and origin=?;
is a query that you will use very often,
Hi,
You are not using any indicies, because there aren't any that could be
used in this query.
Try adding an index on (status,deleted)
I wonder: how many possible different values would such an index
return? If this is a (very) low value, won't the index make things
slower (if it's being
Martijn Tonies wrote:
Hi,
You are not using any indicies, because there aren't any that could be
used in this query.
Try adding an index on (status,deleted)
I wonder: how many possible different values would such an index
return?
mysql select distinct status, deleted from urlword;
Hi,
You are not using any indicies, because there aren't any that could be
used in this query.
Try adding an index on (status,deleted)
I wonder: how many possible different values would such an index
return?
mysql select distinct status, deleted from urlword;
