MySQL releases are now built on all platforms using
CMake rather than the GNU autotools, so
autotools support has been removed. For instructions on building
Installing MySQL from Source. If you are familiar with
autotools but not CMake, you might find this
transition document helpful:
to CMake Transition Guide. Third-party tools that need
to extract the MySQL version number formerly found in
configure.in can use the
VERSION file. See
MySQL Configuration and Third-Party Tools.
Functionality Added or Changed
The time zone tables available at http://dev.mysql.com/downloads/timezones.html have been updated. These tables can be used on systems such as Windows or HP-UX that do not include zoneinfo files. (Bug #40230)
Support for the
IBMDB2I storage engine has
For an upgrade to MySQL 5.5.7 from a previous release, the
server exited if the
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.
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
The following words are no longer reserved words the way they
are in earlier MySQL 5.5 releases:
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
Now the global
can be set at server startup, and this value is used to
initialize the session value for all new connections, including
those for users with the
SUPER privilege. The
variable is treated as a boolean value so it can be enabled with
It can be disabled with
--bind-address option has been
added to a number of MySQL client programs:
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
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
AUTO are supposed to be used only for
debugging, not for production environments.
References: See also Bug #28760.
Security Fix: A security bug was fixed. (Bug #55146, Bug #56287)
Security Fix: A security bug was fixed. (Bug #56814)
Security Fix: A security bug was fixed. (Bug #54484)
Security Fix: A security bug was fixed. (Bug #57130)
Security Fix: A security bug was fixed. (Bug #57272)
Security Fix: A security bug was fixed. (Bug #57477)
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 #58005)
The following changes were made to the
for conformance with the implementation in MySQL 5.6:
Previously, tables in the
database had uppercase names. This was incompatible with the
variable, and caused issues when the variable value was changed
after installing or upgrading.
performance_schema table names are
lowercase, so they appear in uniform lettercase regardless of
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
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:
files from the data directory.
Create a separate “dummy” MySQL 5.5.8 installation.
from the dummy installation to the installation you are
Restart mysqld and run mysqld_upgrade --force and check that it does not produce errors.
Remove the dummy installation.
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
statement tried to update data through a DML statement while
another connection tried to execute
FLUSH TABLES WITH READ
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
was replaced with metadata locks on events. As a result, DDL
operations on events are now prohibited under
LOCK TABLES. This is an
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
Waiting for global read
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
FLUSH TABLES WITH
READ LOCK was waiting to acquire a global read
Waiting for global read
lock is used for both cases.
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,
trigger metadata lock and
event metadata lock.
(Bug #57006, Bug #11764195, Bug #54673, Bug #11762116)
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
References: This bug is a regression of Bug #54582.
InnoDB system tablespace could grow
continually for a server under heavy load.
Values could be truncated in certain
INFORMATION_SCHEMA columns, such as
A followup fix to bug #54678.
TABLE could still cause a crash (assertion error) in
the debug version of the server.
A large number of foreign key declarations could cause the
output of the
SHOW CREATE STATEMENT statement
to be truncated.
InnoDB table created with
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.
Heavy concurrent updates of a
BLOB column in an
InnoDB table could cause a hang.
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
ROW_FORMAT=COMPRESSED clause. on the
ALTER TABLE statement.
Any valid, nondefault
takes precedence over
both are specified.
ROW_FORMAT is not specified on either the
CREATE TABLE or
TABLE statement, or is specified as
DEFAULT. In case of a conflict between
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.
KEY_BLOCK_SIZE=0 is now permitted
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
as if it had not been specified. That default is 8 if
KEY_BLOCK_SIZE is not used or stored with the
As a consequence of this fix,
ROW_FORMAT=FIXED is not permitted when
innodb_strict_mode is enabled.
InnoDB: The server could stop with an assertion error on Windows Vista and Windows 7 systems. (Bug #57720)
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.
Clarified the message when a
statement fails because a foreign key constraint does not have
the required indexes.
In debug builds, an
INSERT ... ON DUPLICATE
statement on an
col_name = 0
AUTO_INCREMENT column caused
the server to crash.
ALTER TABLE operations (that do not
involve a table copy) on a partitioned table could leave the
table in an unusable state.
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
takes an exclusive metadata lock on all stored functions and
stored procedures that it causes to be dropped.
References: See also Bug #30977.
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
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
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.
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
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
Following this fix, if an ongoing transaction contains
TABLE statements, or both, the SQL thread now waits
until the transaction ends, then stops.
(Bug #56118, Bug #11763416)
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.
Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. (Bug #38718)
ENUM columns represented using
more than 1 byte (that is,
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
References: See also Bug #53528.
When replicating the
Grantor column was not replicated, and
was thus left empty on the slave.
find_files() function used by
SHOW statements performed
redundant and unnecessary memory allocation.
The server could crash inside
reading certain Performance Schema tables.
(Bug #56761, Bug #58003)
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)
Handling of host name lettercase in
GRANT statements was
A user with no privileges on a stored routine or the
mysql.proc table could discover the routine's
Several compilation problems were fixed. (Bug #57992, Bug #57993, Bug #57994, Bug #57995, Bug #57996, Bug #57997, Bug #58057)
On file systems with case insensitive file names, and
server could crash due to a table definition cache
Clients using a client library older than MySQL 5.5.7 suffered
loss of connection after executing
connected to a 5.5.7 server.
For CMake builds, some parts of the source were unnecessarily compiled twice if the embedded server was built. (Bug #55647)
Boolean command options caused an error if given with an option
value and the
loose- option prefix.
The server could crash as a result of accessing freed memory
INFORMATION_SCHEMA.VIEWS if a view
could not be opened properly.
debug could cause a crash on Solaris if the server
failed to open the trace file.
variable at server startup did not work.
mysql_upgrade failed after an upgrade from MySQL 5.1. (Bug #58514)
The Performance Schema did not count I/O for the binary log file. (Bug #58052)
SHOW PROCESSLIST displayed
non-ASCII characters improperly.
CMake “wrapper” for
did not handle the
In debug builds, a missing
mysql to be unable to connect to the server.
In debug builds, an assertion could be raised during conversion of strings to floating-point values. (Bug #57203)
When configuring the build with
-DBUILD_CONFIG=mysql_release and building
with Visual Studio Express, the build failed if
signtool.exe was not present.
When configuring the build with
-DBUILD_CONFIG=mysql_release on Linux,
libaio is required, but the error message if
it was missing was uninformative.
Incorrect error handling raised an assertion if character set conversion wrapped an item that failed. (Bug #57882)
Queries executed using the Index Merge access method and a temporary file could return incorrect results. (Bug #56862)
Grouping by a
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.
The Windows sample option files contained values more appropriate for Linux. (Bug #50021)
After creation of a table with two foreign key constraints, the
table displayed only one of them.
An error in a stored procedure could leave the session in a different default database. (Bug #54375)
Failure to create a thread to handle a user connection could cause a server crash. (Bug #58080)
Memory was allocated in
storing path names, but not freed anywhere.
Valgrind warnings about overlapping memory when double-assigning the same variable were corrected. (Bug #56138)
NAME_CONST() in a
HAVING clause caused a server crash.
cmake/mysql_version.cmake failed if
LINK_FLAGS was modified.
MySQL-shared RPM package failed to
provide the lowercase virtual identifier
'mysql-shared' in the RPM
'Provides' tags (usually used for backward
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)
file_name argument to the
--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.
With CMake 2.8.3, the
option did not work.
In debug builds, an assertion could be raised if a
send_eof() method was called after an error
ARCHIVE storage engine could
not be loaded with DTrace enabled on Solaris.
(Bug #47739, Bug #11755901)
INDEX did not always force the index.
(Bug #42209, Bug #11751370)
SET NAMES utf8
COLLATE utf8_sinhala_ci did not work.
utf16_bin collation uses code-point
order, not byte-by-byte order, as described at
Unicode Character Sets. (The order was
byte-by-byte in MySQL 5.5.7.)