Connecting Tech Pros Worldwide Help | Site Map

MySQL prepare statement performance bottom-neck

howachen@gmail.com
Guest
 
Posts: n/a
#1: Jun 30 '06
Hi,

When doing mysql query (SELECT statements) in php, we often use prepare
statement to prevent SQL injection. However, I just noticed that the
prepare statements can SLOW the number of queries per second by a
factor of 2 times (max).

So are there any faster method that can prevent SQL injection, but has
a better performance?

Thanks.

Richard Levasseur
Guest
 
Posts: n/a
#2: Jun 30 '06

re: MySQL prepare statement performance bottom-neck



If it is MySQL < 4.1, then you are using emulated prepared statements,
which may be causing the slowdown. It wouldn't surprise me if PEAR was
doing some funny regex's to parse the queries, escape the values, etc.

If you're using a database abstraction library, maybe try switching the
abstraction library (See PDO and Adodb, among others), it might speed
things up.

It should also be noted that using prepare/execute requires 2 trips to
the server
(http://dev.mysql.com/tech-resources/...atements.html),
since it has to send it to be parsed, then send it to be executed.
This would account for the exact factor of 2.


howachen@gmail.com wrote:[color=blue]
> Hi,
>
> When doing mysql query (SELECT statements) in php, we often use prepare
> statement to prevent SQL injection. However, I just noticed that the
> prepare statements can SLOW the number of queries per second by a
> factor of 2 times (max).
>
> So are there any faster method that can prevent SQL injection, but has
> a better performance?
>
> Thanks.[/color]

howachen@gmail.com
Guest
 
Posts: n/a
#3: Jul 1 '06

re: MySQL prepare statement performance bottom-neck



Richard Levasseur 寫道:
[color=blue]
> If it is MySQL < 4.1, then you are using emulated prepared statements,
> which may be causing the slowdown. It wouldn't surprise me if PEAR was
> doing some funny regex's to parse the queries, escape the values, etc.
>
> If you're using a database abstraction library, maybe try switching the
> abstraction library (See PDO and Adodb, among others), it might speed
> things up.
>
> It should also be noted that using prepare/execute requires 2 trips to
> the server
> (http://dev.mysql.com/tech-resources/...atements.html),
> since it has to send it to be parsed, then send it to be executed.
> This would account for the exact factor of 2.
>
>
> howachen@gmail.com wrote:[color=green]
> > Hi,
> >
> > When doing mysql query (SELECT statements) in php, we often use prepare
> > statement to prevent SQL injection. However, I just noticed that the
> > prepare statements can SLOW the number of queries per second by a
> > factor of 2 times (max).
> >
> > So are there any faster method that can prevent SQL injection, but has
> > a better performance?
> >
> > Thanks.[/color][/color]

Thanks...

So is that means in order to prevent SQL injection, we must need this
kind of overhead?

Richard Levasseur
Guest
 
Posts: n/a
#4: Jul 1 '06

re: MySQL prepare statement performance bottom-neck



howachen@gmail.com wrote:[color=blue]
> Richard Levasseur 寫道:
>[color=green]
> > If it is MySQL < 4.1, then you are using emulated prepared statements,
> > which may be causing the slowdown. It wouldn't surprise me if PEAR was
> > doing some funny regex's to parse the queries, escape the values, etc.
> >
> > If you're using a database abstraction library, maybe try switching the
> > abstraction library (See PDO and Adodb, among others), it might speed
> > things up.
> >
> > It should also be noted that using prepare/execute requires 2 trips to
> > the server
> > (http://dev.mysql.com/tech-resources/...atements.html),
> > since it has to send it to be parsed, then send it to be executed.
> > This would account for the exact factor of 2.
> >
> >
> > howachen@gmail.com wrote:[color=darkred]
> > > Hi,
> > >
> > > When doing mysql query (SELECT statements) in php, we often use prepare
> > > statement to prevent SQL injection. However, I just noticed that the
> > > prepare statements can SLOW the number of queries per second by a
> > > factor of 2 times (max).
> > >
> > > So are there any faster method that can prevent SQL injection, but has
> > > a better performance?
> > >
> > > Thanks.[/color][/color]
>
> Thanks...
>
> So is that means in order to prevent SQL injection, we must need this
> kind of overhead?[/color]

You could manually escape the values before you query, its just a lot
more work to $databaseHandle->escape($value) for every user submitted
value. This would most likely solve the performance problem.

Closed Thread