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
>
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;
> +
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 fr
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 u
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
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 wh
