I witnessed this with MYSQL 3.23.xx recently. In fact, what happened was multiple identical queries fired off, and use /tmp for temporary tables. So many of them fired off that there were hundreds of temporary tables in /tmp, such that it filled /tmp - what was around 1GB or so. Doing "show full processlist" showed the identical queries all running (or waiting for their temp tables do find more disk space). This lead me to testing the execution in MySQL 5.0, but in a very rough way - do a query that takes a few seconds (with no query cache, but with the tables already buffered in memory, etc). Then try and do two simultanously and compare the time it takes (ie, two windows, change window and execute). With a clean but enabled cache ("reset query cache"), both queries took some (considerable) time; neither showed signs of blocking waiting for the first thread to populate the query cache.
Does anyone here know this section of the code? I haven't looked at source, but am guessing that the cache is populated when results return from executing; given we have multiple threads accessing the cache to fetch results, if one thread has already started executing, what value is there in a second thread starting the identical same query -- if subsequent threads waited a few cycles the cache would be populated and a huge performance win? Obviously once the cache is populated this is irrelevent.
James Bromberger,
http://www.james.rcpt.to