The following words are no longer reserved words the way they
are in earlier MySQL 5.5 releases: SLOW,
GENERAL,
IGNORE_SERVER_IDS,
MASTER_HEARTBEAT_PERIOD
(Bug #57899)

For an upgrade to MySQL 5.5.7 from a previous release, the
server exited if the mysql.proxies_priv table
did not exist, making upgrades inconvenient. Now the server
treats a missing proxies_priv table as
equivalent to an empty table. However, after starting the
server, you should still run mysql_upgrade to
create the table.
(Bug #57551)

The autocommit system variable
is enabled by default for all user connections, and the session
value can be set for each new connection by setting the
init_connect system variable to
SET autocommit=0. However, this has no effect
for users who have the SUPER
privilege.

The client/server protocol now includes a
SERVER_QUERY_WAS_SLOW flag to indicate when a
query is slow; that is, when query execution exceeds the value
of the long_query_time system
variable.
(Bug #57058)

A --bind-address option has been
added to a number of MySQL client programs:
mysql, mysqldump,
mysqladmin, mysqlbinlog,
mysqlcheck, mysqlimport,
and mysqlshow. This is for use on a computer
having multiple network interfaces, and enables you to choose
which interface is used to connect to the MySQL server.

A corresponding change was made to the
mysql_options() C API function,
which now has a MYSQL_OPT_BIND option for
specifying the interface. The argument is a host name or IP
address (specified as a string).

Changes to replication in MySQL 5.6 make
mysqlbinlog output generated by the
--base64-output=ALWAYS
option unusable, so ALWAYS is now deprecated
and will be an invalid option value in MySQL 5.6. This should
not be a significant problem because
--base64-output values other
than AUTO are supposed to be used only for
debugging, not for production environments.

References: See also Bug #28760.

Bugs Fixed

Security Fix; InnoDB:
A failed CREATE TABLE statement
for an InnoDB table could allocate
memory that was never freed.
(Bug #56947)

Security Fix:
A security bug was fixed.
(Bug #58005)

Security Fix:
A security bug was fixed.
(Bug #57687)

Security Fix:
A security bug was fixed.
(Bug #57659)

Security Fix:
A security bug was fixed.
(Bug #57477)

Security Fix:
A security bug was fixed.
(Bug #57272)

Security Fix:
A security bug was fixed.
(Bug #57130)

Security Fix:
A security bug was fixed.
(Bug #56814)

Security Fix:
A security bug was fixed.
(Bug #55146, Bug #56287)

Security Fix:
A security bug was fixed.
(Bug #54484)

Performance; InnoDB:
Improved concurrency when several ANALYZE
TABLE or SHOW TABLE
STATUS statements are run simultaneously for
InnoDB tables.
(Bug #53046)

Incompatible Change:
Previously, tables in the performance_schema
database had uppercase names. This was incompatible with the
lower_case_table_names system
variable, and caused issues when the variable value was changed
after installing or upgrading.

Now performance_schema table names are
lowercase, so they appear in uniform lettercase regardless of
the lower_case_table_names
setting. References to these tables in SQL statements should be
given in lowercase. This is an incompatible change, but provides
compatible behavior across different values of
lower_case_table_names.

If you upgrade to MySQL 5.5.8 from an earlier version of MySQL
5.5, be sure to run mysql_upgrade (and
restart the server) to change the names of existing
performance_schema tables from uppercase to
lowercase. If mysql_upgrade does not work,
use this procedure:

Stop mysqld.

Remove the performance_schema/*.frm
files from the data directory.

Create a separate “dummy” MySQL 5.5.8
installation.

Copy the performance_schema/*.frm files
from the dummy installation to the installation you are
upgrading.

Restart mysqld and run
mysqld_upgrade --force and check that it
does not produce errors.

Remove the dummy installation.

(Bug #57609)

Incompatible Change:
The following changes were made to the
performance_schema.threads table
for conformance with the implementation in MySQL 5.6:

ID column: Renamed to
PROCESSLIST_ID, removed NOT
NULL from definition.

Incompatible Change:
Starvation of FLUSH
TABLES WITH READ LOCK statements occurred when there
was a constant load of concurrent DML statements in two or more
connections. Deadlock occurred when a connection that had some
table open through a HANDLER
statement tried to update data through a DML statement while
another connection tried to execute
FLUSH TABLES WITH READ
LOCK concurrently.

These problems resulted from the global read lock
implementation, which was reimplemented with the following
consequences:

To solve deadlock in event-handling code that was exposed by
this patch, the LOCK_event_metadata mutex
was replaced with metadata locks on events. As a result, DDL
operations on events are now prohibited under
LOCK TABLES. This is an
incompatible change.

The global read lock
(FLUSH TABLES WITH
READ LOCK) no longer blocks DML and DDL on
temporary tables. Before this patch, server behavior was not
consistent in this respect: In some cases, DML/DDL
statements on temporary tables were blocked; in others, they
were not. Since the main use cases for
FLUSH TABLES WITH
READ LOCK are various forms of backups and
temporary tables are not preserved during backups, the
server now consistently permits DML/DDL on temporary tables
under the global read lock.

The set of thread states has changed:

Waiting for global metadata lock is
replaced by Waiting for global read
lock.

Previously, Waiting for release of
readlock was used to indicate that DML/DDL
statements were waiting for release of a read lock and
Waiting to get readlock was used to
indicate that
FLUSH TABLES WITH
READ LOCK was waiting to acquire a global read
lock. Now Waiting for global read
lock is used for both cases.

Previously, Waiting for release of
readlock was used for all statements that
caused an explicit or implicit commit to indicate that
they were waiting for release of a read lock and
Waiting for all running commits to
finish was used by
FLUSH TABLES WITH
READ LOCK. Now Waiting for commit
lock is used for both cases.

There are two other new states, Waiting for
trigger metadata lock and Waiting for
event metadata lock.

(Bug #57006, Bug #11764195, Bug #54673, Bug #11762116)

InnoDB:
Values could be truncated in certain
INFORMATION_SCHEMA columns, such as
REFERENTIAL_CONSTRAINTS.REFERENCED_TABLE_NAME
and KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME.
(Bug #57960)

InnoDB:
For an InnoDB table created with
ROW_FORMAT=COMPRESSED or
ROW_FORMAT=DYNAMIC, a query using the
READ UNCOMMITTED isolation level could cause
the server to stop with an assertion error, if
BLOB or other large columns that use off-page
storage were being inserted at the same time.
(Bug #57799)

InnoDB:
The server could stop with an assertion error on Windows Vista
and Windows 7 systems.
(Bug #57720)

InnoDB:
A followup fix to bug #54678. TRUNCATE
TABLE could still cause a crash (assertion error) in
the debug version of the server.
(Bug #57700)

InnoDB:
If the MySQL Server crashed immediately after creating an
InnoDB table, the server could quit with a
signal 11 during the subsequent restart. The
issue could occur if the server halted after
InnoDB created the primary index for the
table, but before the index definition was recorded in the MySQL
metadata.
(Bug #57616)

References: This bug is a regression of Bug #54582.

InnoDB:
The InnoDB system tablespace could grow
continually for a server under heavy load.
(Bug #57611)

InnoDB:
Heavy concurrent updates of a
BLOB column in an
InnoDB table could cause a hang.
(Bug #57579)

InnoDB:
A query for an InnoDB table could
return the wrong value if a column value was changed to a
different case, and the column had a case-insensitive index.
(Bug #56680, Bug #11763909)

InnoDB:
An existing InnoDB table could be switched to
ROW_FORMAT=COMPRESSED implicitly by a
KEY_BLOCK_SIZE clause in an
ALTER TABLE statement. Now, the
row format is only switched to compressed if there is an
explicit ROW_FORMAT=COMPRESSED clause. on the
ALTER TABLE statement.

Any valid, nondefault ROW_FORMAT parameter
takes precedence over KEY_BLOCK_SIZE when
both are specified. KEY_BLOCK_SIZE only
enables ROW_FORMAT=COMPRESSED if
ROW_FORMAT is not specified on either the
CREATE TABLE or ALTER
TABLE statement, or is specified as
DEFAULT. In case of a conflict between
KEY_BLOCK_SIZE and
ROW_FORMAT clauses, the
KEY_BLOCK_SIZE is ignored if
innodb_strict_mode is off, and the statement
causes an error if innodb_strict_mode is on.
(Bug #56632)

InnoDB:
The clause KEY_BLOCK_SIZE=0 is now permitted
on CREATE TABLE and
ALTER TABLE statements for
InnoDB tables, regardless of the setting of
innodb_strict_mode. The zero
value has the effect of resetting the
KEY_BLOCK_SIZE table parameter to its default
value, depending on the ROW_FORMAT parameter,
as if it had not been specified. That default is 8 if
ROW_FORMAT=COMPRESSED. Otherwise,
KEY_BLOCK_SIZE is not used or stored with the
table parameters.

As a consequence of this fix,
ROW_FORMAT=FIXED is not permitted when
innodb_strict_mode is enabled.
(Bug #56628)

InnoDB:
A large number of foreign key declarations could cause the
output of the SHOW CREATE STATEMENT statement
to be truncated.
(Bug #56143)

InnoDB:
Clarified the message when a CREATE TABLE
statement fails because a foreign key constraint does not have
the required indexes.
(Bug #16290)

Partitioning:
In-place ALTER TABLE operations (that do not
involve a table copy) on a partitioned table could leave the
table in an unusable state.
(Bug #57985)

Replication:
Concurrent statements using a stored function and a
DROP DATABASE statement that
caused the same stored function to be dropped could cause
statement-based replication to fail. This problem is resolved by
making sure that DROP DATABASE
takes an exclusive metadata lock on all stored functions and
stored procedures that it causes to be dropped.
(Bug #57663)

References: See also Bug #30977.

Replication:
When STOP SLAVE is issued, the
slave SQL thread rolls back the current transaction and stops
immediately if the transaction updates only tables which use
transactional storage engines. Previously, this occurred even
when the transaction contained
CREATE TEMPORARY
TABLE statements,
DROP TEMPORARY
TABLE statements, or both, although these statements
cannot be rolled back. Because temporary tables persist for the
lifetime of a user session (in the case, the replication user),
they remain until the slave is stopped or reset. When the
transaction is restarted following a subsequent
START SLAVE statement, the SQL
thread aborts with an error that a temporary table to be created
(or dropped) already exists (or does not exist, in the latter
case).

Following this fix, if an ongoing transaction contains
CREATE TEMPORARY
TABLE statements,
DROP TEMPORARY
TABLE statements, or both, the SQL thread now waits
until the transaction ends, then stops.
(Bug #56118, Bug #11763416)

Replication:
If there exist both a temporary table and a nontemporary table
having the same name, updates normally apply only to the
temporary table, with the exception of a
CREATE
TABLE ... SELECT statement that creates a nontemporary
table having the same name as an existing temporary table. When
such a statement was replicated using the
MIXED logging format, and the statement was
unsafe for row-based logging, updates were misapplied to the
temporary table.

Updates were also applied wrongly when a temporary table that
used a transactional storage engine was dropped inside a
transaction, followed by updates within the same transaction to
a nontemporary table having the same name.
(Bug #55478)

References: See also Bug #47899, Bug #55709.

Replication:
When making changes to relay log settings using
CHANGE MASTER TO, the I/O cache
was not cleared. This could result in replication failure when
the slave attempted to read stale data from the cache and then
stopped with an assertion.
(Bug #55263)

Replication:
Replication of SET and
ENUM columns represented using
more than 1 byte (that is, SET
columns with more than 8 members and
ENUM columns with more than 256
constants) between platforms using different endianness failed
when using the row-based format. This was because columns of
these types are represented internally using integers, but the
internal functions used by MySQL to handle them treated them as
strings.
(Bug #52131)

References: See also Bug #53528.

Replication:
Trying to read from a binary log containing a log event of an
invalid type caused the slave to crash.
(Bug #38718)

Replication:
When replicating the mysql.tables_priv table,
the Grantor column was not replicated, and
was thus left empty on the slave.
(Bug #27606)

Setting the read_only system
variable at server startup did not work.
(Bug #58669)

mysql_upgrade failed after an upgrade from
MySQL 5.1.
(Bug #58514)

When configuring the build with
-DBUILD_CONFIG=mysql_release and building
with Visual Studio Express, the build failed if
signtool.exe was not present.
(Bug #58313)

Passing a string that was not null-terminated to
UpdateXML() or
ExtractValue() caused the server
to fail with an assertion.
(Bug #57279, Bug #11764447)

SET GLOBAL
debug could cause a crash on Solaris if the server
failed to open the trace file.
(Bug #57274)

In debug builds, an assertion could be raised during conversion
of strings to floating-point values.
(Bug #57203)

If the file_name argument to the
--defaults-file or
--defaults-extra-file option was not a full
path name, it could be interpreted incorrectly in some contexts
and cause a server crash. Now the
file_name argument is interpreted as
relative to the current working directory if given as a relative
path name rather than as a full path name.
(Bug #57108)

A user with no privileges on a stored routine or the
mysql.proc table could discover the routine's
existence.
(Bug #57061)

Warnings raised by a trigger were not cleared upon successful
completion. Now warnings are cleared if the trigger completes
successfully, per the SQL standard.
(Bug #55850)

For CMake builds, some parts of the source
were unnecessarily compiled twice if the embedded server was
built.
(Bug #55647)

In debug builds, an assertion could be raised if a
send_eof() method was called after an error
occurred.
(Bug #54812)

Boolean command options caused an error if given with an option
value and the loose- option prefix.
(Bug #54569)

An error in a stored procedure could leave the session in a
different default database.
(Bug #54375)

The CMake“wrapper” for
configure (configure.pl)
did not handle the --with-comment option
properly.
(Bug #52275)

Grouping by a TIME_TO_SEC()
function result could cause a server crash or incorrect results.
Grouping by a function returning a
BLOB could cause an unexpected
“Duplicate entry” error and incorrect result.
(Bug #52160)

The find_files() function used by
SHOW statements performed
redundant and unnecessary memory allocation.
(Bug #51208)

The ARCHIVE storage engine could
not be loaded with DTrace enabled on Solaris.
(Bug #47739, Bug #11755901)

Error messages for several delegate-related initialization error
conditions that should not occur were changed to help identify
the area of failure and to instruct the user to file a bug
report if they do occur. A delegate is a set of internal data
structures and algorithms.
(Bug #47027)

On file systems with case insensitive file names, and
lower_case_table_names=2, the
server could crash due to a table definition cache
inconsistency.
(Bug #46941)