I\'ve been troubleshooting this complex query today, thinking it was a performance issue. It appears that the query is getting stuck into the \'Statistics\' state. It is current
I had the same issue on a Centos server 4 cores and 180GB ram. A simple query was taking forever to run and stuck on statistics state just like what you have explained. I ran OPTIMIZE TABLE
on the tables it was querying and like 5 minutes later problem was solved. However, I never found out if it really solved the issue or not.
Just a suggestion.
I ran into the same problem recently: MySQL started to choke (stuck in state 'statistics') on queries with a lot of tables joined together. I found a good blog post explaining why this happens and how to solve it.
Basically at least in MySQL 5.5, the default value for the configuration parameter optimizer_search_depth is 62 which will cause the query optimizer to take exponentially more time as the number of tables in the query increases. After a certain point it will start to take days or even longer to finish the query.
However, if you set the optimizer_search_depth to 0 in your my.cnf, MySQL automatically chooses suitable depth, but limits it to 7 which is not yet too complex.
Apparently this issue has been fixed in MySQL 5.6 but I haven't tested it myself yet.