Let me change your example slightly... select * from table where name>’A’ versus select * from table where name>’Z’
Now, let's assume you have an INDEX starting with `name` and names are distributed in the typical way. The will be perhaps 1% of the names satisfying >'Z', but 95% satisfying >'A'. The index would be very useful for Z, but a waste for A. Hence, it is a "feature" that MySQL does not cache execution plans. You will also find that MySQL's query analyzer is very fast (compared to the competition). Hence, there is much less need for a cache than 'they' have. > -----Original Message----- > From: Johan De Meersman [mailto:vegiv...@tuxera.be] > Sent: Monday, August 13, 2012 5:49 AM > To: MID.night > Cc: 673575760; mysql > Subject: Re: Hi, how did u do de-emphasis of sql statements? > > > > ----- Original Message ----- > > From: "MID.night" <693893...@qq.com> > > > > Like select * from table where name>’A’ is just > > > > The same as select * from table where name>’B’. > > The execution plan for both statements is indeed likely (but not > guaranteed!) to be the same. As far as I'm aware, though, MySQL does > not bother about that, though, as there is no execution plan cache. > > The query result cache does not equate the statements - it works based > off the EXACT query text, INCLUDING spaces and capitalization. > > When analyzing various logs, the Maatkit/Aspersa/Percona toolset does > transform SQL statements into their canonical form, though; so if > you're looking for ways to do that you can have a look at how it's done > there. > > > -- > Linux Bier Wanderung 2012, now also available in Belgium! > August, 12 to 19, Diksmuide, Belgium - http://lbw2012.tuxera.be > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql
