Reputation: 31
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.
Upvotes: 3
Views: 1728
Reputation: 381
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
Upvotes: 1