As of MySQL 5.1.25, metadata changes to tables or views referred
to by prepared statements are detected and cause automatic
repreparation of the statement when it is next executed. This
applies to prepared statements processed at the SQL level (using
PREPARE statement) and those
processed using the binary client/server protocol (using the
mysql_stmt_prepare() C API
The server attempts repreparation up to three times. An error occurs if all attempts fail.
Metadata changes occur for DDL statements such as those that
create, drop, alter, rename, or truncate tables, or that analyze,
optimize, or repair tables. Repreparation also occurs after
referenced tables or views are flushed from the table definition
cache, either implicitly to make room for new entries in the
cache, or explicitly due to
Repreparation is automatic, but to the extent that it occurs, diminishes prepared statement performance.
Repreparation uses the default database and SQL mode that were in effect for the original preparation.
status variable tracks the number of repreparations.
An incompatibility with older versions of MySQL (before 5.1.25) is
that a prepared statement may return a different set of columns or
different column types from one execution to the next. For
example, if the prepared statement is
SELECT * FROM
t1 to contain a
different number of columns causes the next execution to return a
number of columns different from the previous execution.
Older versions of the client library cannot handle this change in behavior. For applications that use prepared statements with a server that performs automatic repreparation, an upgrade to the new client library is strongly recommended.