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