Thanks for info. I have not seen this being the problem so far though it may be good thing to be fixed. There is a lot which can/should be changed about how Innodb computes stats.

I just happened to run across this while looking at a bug in MyISAM. I’ve not checked out the behavior in MySQL (so I could be wrong), but it looks like Innodb only updates the current table and not the global share (like MyISAM does). So analyze may be a local only modifier for the current session for Innodb. I’ve noticed that both PBXT and MyISAM update the global, though since the optimizer never takes a lock on the share (ie the table definition) there is a remote chance that they values may be @$#@#$. I don’t believe there is any later “magic” that occurs that closed the table and replaces the global values in a way to protect the variables, but I could be wrong.

If you are curious about the code look at ha_innodb.cc and search for HA_STATUS_CONST. Closing and reopening all “Handler” on the table will also cause this to be recalculated.

Cheers,
-Brian

Each one of the queries that are displayed in this page has a specific display format which includes the query itself, the result set (neatly separated with stripped lines) & the time it took to execute.

How did you do that?
I see this query-display-format in many developers websites.
It seems that you use an SQL tools for that.

Thanks in advance,
Dor.

I fully agree with you.
I’ve faced the same problem at a customer.

When the customer switched from MyISAM to InnoDb some queries that before took > 1 sec now took several minutes.
The reason we slightly wrong stats in the innodb analyse which made the optimizer create tabsolutely wrong query plans.

All these queries could be fixed with manually hinting with STRAIGHT_JOIN or FORCE INDEX.

But of course it would have been much nicer if the stats would be correct on inno.

Did you file a bug for this already?

Well Analyze for Innodb can be helpful… It gives you cardinalities which are at least show the order of magnitude for cardinality which can help certain join queries.

The OPTIMIZE TABLE… this is good to have for Innodb in theory but in practice because this rebuilds the whole table it is most typically too slow to be useful. There are cases when OPTIMIZE takes weeks to complete. Plus because it builds indexes via “inserts” it does not really optimize things as well as it could. And the table will be read only for the whole duration

MySQL 5.1 Innodb plugin can build indexes faster but you need to do particular way of dump and reload to get benefit of this fast load.

You’ve made my day ! Thanks a lot for those informations/tests.