Mysql query execution plan has caching?

Question

I've looked everywhere for my issue but found no definite answer. Database: MySQL Given three numerical fields a, b, c and One datetime filed d, all indexed separately The involved table holds 10 mil. records.

Two numbers n,m

I have a basic query:

select * where (a=n or b=n) and c IN(m) Order by d DESC

(n can be any number, m can be any number through 1-9) I also have a separate index on each one of them. I've tried indexes on ac and bc but with no success.

On my development environment I always get an index merge which makes the query fast even though it makes a filesort for some reason that I dont' really care about.

But on production(different sever-same schema/data) that doesn't happen no matter what I do.

My workaround to this weird issue was turning the query into the following statement:

From:

select * where (a=n or b=n) and c IN(m) ORDER BY d desc

To:

select * where (a=n or b=n) and c IN(m,'m') ORDER BY d desc

And that resulted in an merge index query on the production environment as well which basically for me means that there's an execution plan cache somewhere and I can't figure out for the life of me where to clear that cache (if indeed there is one)

I need to know how can I tell the production environment to properly use that index in the first statement.

As a note ... for some reason Explain query tells me that d is the index used on production when explaining the query.

Answer 1

I need to know how can I tell the production environment to properly use that index in the first statement.

Use the "force index" syntax.

If you paste CREATE TABLE & EXPLAIN output for the tables & queries involved (resp.) on dev & production we can narrow it down to a just a couple things. Might also help to know the RAM available on each machine.

ps:

On my development environment I always get an index merge which makes the query fast even though it makes a filesort for some reason that I dont' really care about.

sorting by d which isn't in your index