What language are you working in?  (Not all have binding)
PREPARE might be using mysql_real_escape_string behind the scenes.  :(

Caching too much of the "prepare" would defeat one important "feature" of 
MySQL:  It's ability to use a different query plan when given different 
constants.

> -----Original Message-----
> From: Johan De Meersman [mailto:vegiv...@tuxera.be]
> Sent: Monday, May 14, 2012 9:17 AM
> To: Reindl Harald
> Cc: mysql@lists.mysql.com
> Subject: Re: MySQL Community Server 5.1.63 has been released
> 
> 
> 
> ----- Original Message -----
> > From: "Reindl Harald" <h.rei...@thelounge.net>
> >
> > but what about the dramatical reduced query-cache hits i see in some
> > peace of software switching to prepared statements?
> >
> > dbmail2 as example had around 300 sql-actions per second
> > dbmail3 using prepared statements currently around 1000 per second
> >
> > i can not imagine any better performance in a php-script since it is
> > stateless and you have to do the whole prepare in each request
> 
> True. I just read up a bit on MySQL's prepared statement handling; and
> while it *does* implement prepared statements, it still doesn't have a
> prepared statement *cache*.
> 
> That is to say, prepared statements are connection-specific, and even
> if you prepare the same statement twice in the same connection it'll
> allocate the structures twice. Kind of... suboptimal :-)
> 
> So yes, it is true that in an application that does not repeatedly
> execute the same query with different parameters, it is likely to
> actually incur a performance penalty. I really really REALLY wish MySQL
> would make work of a global prepared statement cache - then the
> application being stateless wouldn't matter.
> 
> Percona's Peter Zaitsev has an interesting blog post about the whole
> thing here: http://www.mysqlperformanceblog.com/2006/08/02/mysql-
> prepared-statements/
> 
> 
> 
> --
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
> 
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/mysql

Reply via email to