MySQLPerformanceBlog.com did some benchmarks in an article about "Prepared Statements." Peter Zaitsev wrote:
I’ve done a simple benchmark (using
SysBench) to see performance of simple
query (single row point select) using
standard statement, prepared statement
and have it served from query cache.
Prepared statements give 2290
queries/sec which is significantly
better than 2000 with standard
statements but it is still well below
4470 queries/sec when results are
served from query cache.
This seems to say that the "overhead" of using prepared statements is that they are 14.5% faster than using a straight query execution, at least in this simple test. The relative difference probably diminishes with a more complex query or a larger result set.
It seems counter-intuitive that prepared queries would be faster, given the double round-trip to the server and other factors. Peter's benchmark lacks details. Anyway, you should run your own tests, because the type of query you run, and your environment and hardware, are definitely important factors.
As for Query Cache, it was true in the past that prepared statements were incompatible with caching query results, but this was changed. See "How the Query Cache Operates" in the MySQL documentation:
Before MySQL 5.1.17, prepared
statements do not use the query cache.
Beginning with 5.1.17, prepared
statements use the query cache under
certain conditions, which differ
depending on the preparation method: ...
The documentation goes on to describe these conditions. Go read it.
I do recommend using prepared statements for SELECT
queries. Quoting variables as you interpolate them into SQL statements can be effective if you do it consistently. But even quoting may have some subtle security vulnerabilities, e.g. with multi-byte character sets (see MySQL bug #8378). It's easier to use prepared queries in a secure way in these cases.