I had the exact same problem with a lot of queries like this in oracle. Not much of performance until we rewrote the subqueries as joins. Subqueries seem to be a bit of a problem for the oracle optimizer as well. The queries were of course somewhat more complex which did not make it easier for the optimizer.
Maybe the optimizer for MySQL is not that bad after all? Or they both need some work to be done?

Where these queries generated through Hibernate by any chance? In my case they were and if IIRC you could ‘teach’ Hibernate to generate the joins instead of the subqueries. But I do not remember how that was done. Probably to be found in the Hibernate docs.

Looking at volumetric trends shows us also that while disk performance and speed hasn’t improved as much, disk capacity certainly has. There is as such a current imbalance between how much you stack in a disk and how fast you can do it or get it. And I don’t see any hardware way of addressing that imbalance. Other than solid state memory, which is a bit far away at the moment in terms of usable capacity.

All this to say that indexing and optimisers will be here for a long while yet. In fact, looking at Jim Gray’s “Petabyte” musings, I’d say you’ll see even more interesting stuff happening in the field of large scale data storage cataloguing: someone, somehow, somewhere, has to be able to efficiently get at all those PBs!

Thanks for spotting the typo or rather c&p error. This just a dirty example assuming that t2.c1 is a PK, for example. Obviously, I couldn’t share real customer queries. The right statement should be:

SELECT t1.*
   FROM t1, t2
  WHERE t1.c1=t2.c1
    AND t2.c2=100;

In addition to what you said, our customer expressed an interesting point today – would you prefer letting that mainframe software keep you credit card and account balance or it’s fine to move it to Oracle? Now what about MySQL?

Perhaps, some people would answer yes to the second question now. In some time they might even answer yes to the second question.

However, there are people (in fact, majority) that would answer “Why would I care?”. Those are the people who don’t need to know about mainframes, Oracle and MySQL but do need to know that they are able to take cash from the ATM machine anytime and they don’t need to wait few minutes for that. Of course, they have some other requirements like no one else is able to manipulate their account.

If that can be delivered by MySQL at some point – why not?

gorbyx: http://www.pythian.com/blogs/355/mysql-cant-use-index-with-uncorrelated-in-subquery

Paul: interesting observation for you
the faster the underlying hardware, the less valuable oracle’s indexing and optimizing innovations (not to mention patents) become
as as hardware is getting faster faster and faster, these issues become minor issues and then non-issues
this causes enormous depreciation of IBM’s and oracle’s technology and patent portfolios
so ultimately, especially following the millsap what’s the business impact tuning method, these issues with databse platforms are meaningless. if it’s not meaningless now, it’ll be meaningless next year, or the year after that anyway.
in the meantime, it’s cheaper to pay you to rewrite the query than it is to license oracle or db2
gorbyx: well, I see the point. I don’t agree so far but what do I see in my life?
put you comment on the blog – it’s interesting