Re^2: perl mysql question

in reply to Re: perl mysql question
in thread perl mysql question

By calling do(), you didn't actually benefit from prepared SQL statement. As every time you call do(), the statement is prepared on fly, if this do() is executed more than once, the SQL statement will be prepared every and each time.

do() is usually only used for non-repeated non-select SQL statement. The usual way is to prepare() the statement once, and execute() with parameters many times.

Comment on Re^2: perl mysql question

Replies are listed 'Best First'.
Re^3: perl mysql question by Thilosophy (Curate) on Nov 06, 2005 at 07:00 UTC
By calling do(), you didn't actually benefit from prepared SQL statement. While you do not get all the benefits of a properly `prepare`d (and repeatedly re-`execute`d) SQL statement, using placeholders still is a significant improvement even when using `do`, because the SQL is typically also cached in the DB server. So when you `do` the same SQL string the second time, it does not have to be reparsed from scratch (server-side). This even works when someone else connected to the same DB uses the same SQL, which is a good thing because you are probably using more than one connection at the same time. Conversely, not using bind variables can totally kill the scalability of a database application. Of course, re-using prepared statements where possible is the best way, but using bind variables is itself a great (I daresay necessary) improvement (and a good habit, for both performance and security reasons).	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: perl mysql question
by Thilosophy (Curate) on Nov 06, 2005 at 07:00 UTC

By calling do(), you didn't actually benefit from prepared SQL statement.

While you do not get all the benefits of a properly prepared (and repeatedly re-executed) SQL statement, using placeholders still is a significant improvement even when using do, because the SQL is typically also cached in the DB server.

So when you do the same SQL string the second time, it does not have to be reparsed from scratch (server-side). This even works when someone else connected to the same DB uses the same SQL, which is a good thing because you are probably using more than one connection at the same time.

Conversely, not using bind variables can totally kill the scalability of a database application.

Of course, re-using prepared statements where possible is the best way, but using bind variables is itself a great (I daresay necessary) improvement (and a good habit, for both performance and security reasons).

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom