The tests using the statement-at-a-time approach and the prepare statements were both stored in ASCII text files. For the prepare approach, I did one prepare and a million “set … execute” pairs, withe the statement-at-a-time approach, I did a million “update ” commands. I am baffled why the statement-at-a-time approach is faster than the command line “set … execute” approach.

The Perl/DBI should have run faster… strange if it did not. The way to run via command line with “execute using @id” simply has much more statements so it should be faster.
Are you sure you used prepared statements in Perl ? Some versions of DBI will have emulated prepared statements by default so you will not use PS on server in reality.

The statement-at-a-time file looked like:

reset query cache;
update company set data_source_id = data_source_id – 1 where id = 12256006995591;
update company set data_source_id = data_source_id – 1 where id = 120749009859430;
.
. a million rows of updates
.

The prepare/execute file looked like:

reset query cache;
prepare upd from
“update company set data_source_id = data_source_id + 1 where id = ?”;
set @id = 12256006995591;
execute upd using @id;
set @id = 120749009859430;
execute upd using @id;
.
. a million rows repeating set @id = … execute upd using @id
.

I had thought the prepare/execute file would run faster, since supposedly mysql had already done a hard parse on the command. But it ran significantly slower (about 25%) than the statement-at-a-time version. This was consistent over several tries. Also, I tried one version using Perl DBI and its prepare and execute commands and it just did the same data in half the time of the statement-at-a-time version.

There’s not any likelihood of extraneous events screwing up the results. I ran the commands one right after the other, several times, and in different order. Also, they were run on the same machine, my own private server, so there was no contention from other processes to account for the difference. There was no query cache defined and I used different operators for the 2 statements so no command was the same as any other. I even reset the query cache even though it wasn’t being used. So, I’m convinced the results are real.

Why did the prepare/execute script take longer?

So I disagree that prepared statements are always good. If they’re 1,000 times slower than text statements, it’s likely you’ll switch to text rather than buy a 2048 CPU machine with 128G of ram or something like that, or a farm of equivalent size. When handling money definitely. When handling slashdot, not so much.

create procedure table_name(x varchar(100))
begin
select * from x;
end;|

call table_name(’books’);

It shows an error message table x doesnot existt

Any one can help me how to solve this problem

http://euedge.com/blog/2007/11/11/prepared-statement-performance-in-mysql/

This is fixed in MySQL 5.1

But you’re right it should have done long ago