Let me change your example slightly...
select * from table where name>’A’
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:vegivamp@stripped]
> 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" <firstname.lastname@example.org>
> > Like select * from table where name>’Ae 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
> 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