Should I use prepared statements for MySQL in PHP PERFORMANCE-WISE?

Question

I understand the security benefits of prepared statements in MySQL. No need to cover that topic here. I'm wondering about the performance aspect of them.

Now, I know when a query using a prepared statement is executed twice in a single PHP script, it's faster because the query is only parsed once, once for each query. The client makes one trip to prepare, then sends data twice using the binary protocol. The binary protocol is faster, and you're not taking the hit of having to parse a second time.

However, what about the case where I only want to perform a query once in a single PHP script? It would seem using a prepared statement is worse, because you're making two trips to the server, once to prepare, and once to send the data. The benefit of only having to parse once is lost, and you're penalized for that second trip. If the data isn't sufficiently smaller in binary format, you lose by using a prepared statement, right?

However, I've read some conflicting reports about what PHP's mysqli or PDO libraries do? Do either of them cache the prepared statement across script execution? Is the server going to have to parse the prepared statement again on a subsequent pageload or not? If the answer is no, that the statement doesn't have to be parsed on the second pageload, then it would seem that prepared statements ARE better, even if you're only executing the query once per pageload.

Please take into consideration if anything has changed between versions of MySQL regarding this. You can safely assume I'm using PHP 5.2

EDIT: Just to make it clear, I want an answer for MySQL and PHP specifically, specifying the MySQL version and if this was ever different, and to ONLY consider performance, not ease of use or security.

UPDATE: I accepted the answer I did because of the follow up comment had a few good ideas. I'm still a bit disappointed that no one seems to be able to answer the crux of the actual question I asked with any certainty. I guess sometimes the answer really is "it depends."

Answer 1

Using prepared statements is never really a bad idea. I've not used them recently with mySQL, but I've used them heavily with SQLSERVER - and they work great.

The PDO library probably doesn't do any caching but the database will for the prepared statement.

Plus as you covered they are great for security. Its also really nice to push that logic out of the code - you wont up with SQL sprinkled throughout your application.

Answer 2

What exactly do you mean "parsed on the second pageload"?

Each PHP process/thread/visitor that executes that same script again will NOT prevent MySQL from re-parsing the query to prepare the statement, as its valid in a per connection basis, so its very effective for queries repeated in the same script.

Now, I cant argue about prepare + execute vs simple query, performance wise (w/o repeated queries);

But, to save mysql from parsing a complex query in every single script execution, you should use stored procedures; a query would be just CALL items(date,search_etc,id); instead of SELECT i.id FROM products as p JOIN item_prodct as t ON... JOIN items as i... ON... WHERE ... p.date ... i.search_etc ...

You can use stored procedures with prepared statements.

Answer 3

The truth of the matter is that sometimes mysqli is faster and at other times mysql api is faster. But the difference is really really small. If you look at any of the performance tests on the web the difference is really just 10 - 20 milliseconds. The best way to boost performance is to optimize table design.

Many of the tests that 'prove' the older api to be faster conveniently forget that for maximum security mysql_real_escape_string() should be called for each variable used in the query.

Queries are cached by the server, if and only if the data on all the tables that are used in the query have remained unchanged.

Answer 4

The time you may save with one way vs another: 10 milli seconds

The time you save not having to explain to your client why all his user information ended up on 4chan: Priceless

Use prepared statements.

Answer 5

re: "Using prepared statements is never really a bad idea" Not true. You can easily fill up the prepared statement cache and exceed max_prepared_stmt_count if you don't know what you're doing, rendering your app useless until connections consuming the prepared statements are closed. Prepared statements are specifically designed for tight inner loops in your business logic where you're going to be calling the same basic query over and over again, a good example being a parameterized query such as 'select name, address, phone from tbl where id = ?' and you have a different id on each call. That way, it's worth the extra round trip to the db for the prepare because you're probably going to call it hundreds or thousands of times and just change the parameter. But you're expected to remove the prepared statement from the cache or close the connection at the end of, say, your stateless script (php, perl, jsp, ruby, etc). If you don't remove the prepared statement and you are using a connection pool, you are bound to fill up the cache over time and get a nasty error "Can't create more than max_prepared_stmt_count statements". I'm speaking from experience so think about whether you really need prepared statements because you know definitively that you're going to be repeating the same parameterized query over and over in a tight loop. If not, what you're probably looking for is letting mysql use its basic query cache which is a different mechanism than the prepared statement list and which behaves like a true LRU cache from my understanding.