Read all the items in the following sections to see whether any of them might affect your applications:

Note particularly any changes that are marked Known issue or Incompatible change. These incompatibilities with earlier versions of MySQL may require your attention before you upgrade.

Our aim is to avoid these changes, but occasionally they are necessary to correct problems that would be worse than an incompatibility between releases. If any upgrade issue applicable to your installation involves an incompatibility that requires special handling, follow the instructions given in the incompatibility description. Often this will involve a dump and reload, or use of a statement such as CHECK TABLE or REPAIR TABLE.

A dump and reload is done like this:

Any procedure that involves REPAIR TABLE with the USE_FRM option must be done before upgrading. Use of this statement with a version of MySQL different from the one used to create the table (that is, using it after upgrading) may damage the table. See Section 12.5.2.5, “REPAIR TABLE Syntax”.

After you upgrade to a new version of MySQL, run mysql_upgrade (see Section 4.4.8, “mysql_upgrade — Check Tables for MySQL Upgrade”). This program will check your tables, and repair them if necessary. It will also update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. (Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features.)

If you are running MySQL Server on Windows, see Section 2.3.14, “Upgrading MySQL on Windows”.

If you are using replication, see Section 19.3.3, “Upgrading a Replication Setup”, for information on upgrading your replication setup.

Incompatible change: In MySQL 6.0.6, a change was made to the way that the server handles prepared statements. This affects prepared statements processed at the SQL level (using the PREPARE statement) and those processed using the binary client-server protocol (using the mysql_stmt_prepare() C API function).

Previously, changes to metadata of tables or views referred to in a prepared statement could cause a server crash when the statement was next executed, or perhaps an error at execute time with a crash occurring later. For example, this could happen after dropping a table and recreating it with a different definition.

Now 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. 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 FLUSH TABLES.

Repreparation is automatic, but to the extent that it occurs, performance of prepared statements is diminished.

Table content changes (for example, with INSERT or UPDATE) do not cause repreparation, nor do SELECT statements.

An incompatibility with previous versions of MySQL is that a prepared statement may now 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, altering 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 the new server, an upgrade to the new client library is strongly recommended.

Along with this change to statement repreparation, the default value of the table_definition_cache system variable has been increased from 128 to 256. The purpose of this increase is to lessen the chance that prepared statements will need repreparation due to referred-to tables/views having been flushed from the cache to make room for new entries.

A new status variable, Com_stmt_reprepare, has been introduced to track the number of repreparations.

Incompatible change: In MySQL 6.0.6, certain collations were fixed to correctly sort the following characters: TILDE and GRAVE ACCENT in big5_chinese_ci; LATIN SMALL LETTER J in cp866_general_ci; TILDE in gb2312_chinese_ci; and TILDE in gbk_chinese_ci. As a result of this fix, any indexes on columns that use these collations and contain the affected characters must be rebuilt when upgrading to 6.0.6 or higher. To do this, use ALTER TABLE to drop and re-add the indexes, or mysqldump to dump the affected tables and mysql to reload the dump file.

Incompatible change: In MySQL 6.0.5, the utf8_general_ci and ucs2_general_ci collations were fixed to sort the letter "U+00DF SHARP S" equal to 's'. As a result of this fix, any indexes on columns that use these collations (but only columns that use SHARP S) must be rebuilt when upgrading to 6.0.5 or higher. To do this, use ALTER TABLE to drop and re-add the indexes, or mysqldump to dump the affected tables and mysql to reload the dump file.

Incompatible change: As of MySQL 6.0.5, the server includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers:

Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision.

For additional information about the properties of dtoa conversions, see Section 11.2.2, “Type Conversion in Expression Evaluation”.

Incompatible change: As of MySQL 6.0.4, the Unicode implementation has been extended to provide support for supplementary characters that lie outside the Basic Multilingual Plane (BMP). Noteworthy features:

In most respects, upgrading from MySQL 5.1 to 6.0 should present few problems with regard to Unicode usage, although there are some potential areas of incompatibility. Some examples:

Consequently, if you want to upgrade tables from the old utf8 (now utf8mb3) to the current utf8, it may be necessary to change some column or index definitions.

For additional details about the new Unicode character sets and potential incompatibilities, see Section 9.1.8, “Unicode Support”, and Section 9.1.9, “Upgrading from Previous to Current Unicode Support”.

If you use events, a known issue is that if you upgrade from MySQL 5.1 to 6.0.4, the event scheduler will not work, even after you run mysql_upgrade. (This is an issue only for an upgrade, not for a new installation of MySQL 6.0.4.) To work around this upgrading problem, use these instructions:

Incompatible change: As of MySQL 6.0.3, DROP TABLE is allowed only if you have acquired a WRITE lock with LOCK TABLES, or if you hold no locks, or if the table is a TEMPORARY table.

Previously, if other tables were locked, you could drop a table with a read lock or no lock, which could lead to deadlocks between clients. The new stricter behavior means that some usage scenarios will fail when previously they did not.

Incompatible change: Several changes were made to the processing of multiple-table DELETE statements:

Statements containing alias constructs that are no longer allowed must be rewritten.