How to optimize simple MySQL query with lots of INNER JOINS

I've found info on how to optimize MySQL queries, but most of the tips seem to suggest avoiding things MySQL isn't built for (e.g., calculations, validation, etc.) My query on the other hand is very straight forward but joins a lot of tables together.

Is there an approach to speeding up simple queries with many INNER JOINS? How would I fix my query below?

SELECT t_one.id FROM table_one t_one 
INNER JOIN entr_to_state st 
INNER JOIN entr_to_country ct 
INNER JOIN entr_t开发者_运维百科o_domain dm 
INNER JOIN entr_timing t 
INNER JOIN entr_to_weather a2w 
INNER JOIN entr_to_imp_num a2i 
INNER JOIN entr_collection c 
WHERE t_one.type='normal' 
AND t_one.campaign_id = c.id 
AND t_one.status='running' 
AND c.status='running' 
AND (c.opt_schedule = 'continuous' OR (c.opt_schedule = 'schedulebydate' 
AND (c.start_date <= '2011-03-06 14:25:52' AND c.end_date >= '2011-03-06 14:25:52'))) 
AND t.entr_id = t_one.id AND ct.entr_id = t_one.id 
AND st.entr_id = t_one.id AND a2w.entr_id = t_one.id 
AND (t_one.targeted_gender = 'male' OR t_one.targeted_gender = 'both') 
AND t_one.targeted_min_age <= 23.1 AND t_one.targeted_max_age > 23.1 
AND (ct.abbreviation = 'US' OR ct.abbreviation = 'any') 
AND (st.abbreviation = 'CO' OR st.abbreviation = 'any') 
AND t.sun = 1 AND t.hour_14 = 1 
AND (a2w.weather_category_id = 1 OR a2w.weather_category_id = 0) 
AND t_one.targeted_min_temp <= 46 
AND t_one.targeted_max_temp > 46 GROUP BY t_one.id

---

Index all relevant fields, of course, which I'm sure you have

Then find which joins are the most costly ones by running EXPLAIN SELECT...

Consider splitting them off into a seperate query i.e. narrow down the record(s) you're looking for, then perform the joins on those records rather than all the records

i.e.

SELECT c.*, ....
FROM (SELECT x, y, z .... ) AS c

---

You would need to EXPLAIN SELECT the query, check which parts of the query are not using in indices, and then attempt to index those. If possible, break the query down into smaller parts as well.

If you really cannot in any way optimize the underlying DB or your query, you could resort to a flat table that has the data you need for fast access. Then just hook up the main query to update the flat table to run as often as needed.