InnoDB now supports an auto-extending last data file. You do not need to preallocate the whole data file at the database startup.

Made several changes to facilitate the use of the InnoDB Hot Backup tool. It is a separate nonfree tool you can use to take online backups of your database without shutting down the server or setting any locks.

If you want to run the InnoDB Hot Backup tool on an auto-extending data file you have to upgrade it to version ibbackup-0.35.

The log scan phase in crash recovery now runs much faster.

Starting from this server version, the hot backup tool truncates unused ends in the backup InnoDB data files.

To allow the hot backup tool to work, on Windows we no longer use unbuffered I/O or native async I/O; instead we use the same simulated async I/O as on Unix.

You can now define the ON DELETE CASCADE or ON DELETE SET NULL clause on foreign keys.

FOREIGN KEY constraints now survive ALTER TABLE and CREATE INDEX.

We suppress the FOREIGN KEY check if any of the column values in the foreign key or referenced key to be checked is the SQL NULL. This is compatible with Oracle, for example.

SHOW CREATE TABLE now lists also foreign key constraints. Also mysqldump no longer forgets about foreign keys in table definitions.

You can now add a new foreign key constraint with ALTER TABLE ... ADD CONSTRAINT FOREIGN KEY (...) REFERENCES ... (...).

FOREIGN KEY definitions now allow backticks around table and column names.

MySQL command SET TRANSACTION ISOLATION LEVEL ... has now the following effect on InnoDB tables: If a transaction is defined as SERIALIZABLE then InnoDB conceptually adds LOCK IN SHARE MODE to all consistent reads. If a transaction is defined to have any other isolation level, then InnoDB obeys its default locking strategy which is REPEATABLE READ.

SHOW TABLE STATUS no longer sets an x-lock at the end of an auto-increment index if the auto-increment counter has been initialized. This removes in almost all cases the surprising deadlocks caused by SHOW TABLE STATUS.

Fixed a bug: in a CREATE TABLE statement the string 'foreign' followed by a nonspace character confused the FOREIGN KEY parser and caused table creation to fail with errno 150.