Functionality added or changed:
packages are now available. These client library compatibility
packages are like the
package, but are for the “MySQL Enterprise Server
–dash; Advanced Edition” products. Install these
packages rather than the normal
MySQL-shared-compat package if you want to
included shared client libraries for older MySQL versions.
A new status variable,
Queries, indicates the number
of statements executed by the server. This includes statements
executed within stored programs, unlike the
Questions variable which
includes only statements sent to the server by clients.
Previously, index hints did not work for
FULLTEXT searches. Now they work as follows:
For natural language mode searches, index hints are silently
ignored. For example,
IGNORE INDEX(i) is
ignored with no warning and the index is still used.
For boolean mode searches, index hints with
FOR GROUP BY are silently
ignored. Index hints with
FOR JOIN or no
FOR modifier are honored. In contrast to how
hints apply for non-
FULLTEXT searches, the
hint is used for all phases of query execution (finding rows and
retrieval, grouping, and ordering). This is true even if the
hint is given for a non-
Important Change: Replication:
If a trigger was defined on an
InnoDB table and this trigger
updated a nontransactional table, changes performed on the
InnoDB table were replicated and
were visible on the slave before they were committed on the
master, and were not rolled back on the slave after a successful
rollback of those changes on the master.
As a result of the fix for this issue, the semantics of mixing
nontransactional and transactional tables in a transaction in
the first statement of a transaction have changed. Previously,
if the first statement in a transaction contained
nontransactional changes, the statement was written directly to
the binary log. Now, any statement appearing after a
immediately following a
autocommit = 0) is always
considered part of the transaction and cached. This means that
nontransactional changes do not propagate to the slave until the
transaction is committed and thus written to the binary log.
Important Change: The MSI installer packages for Windows are now digitally signed with a certificate, allowing installation on Windows where only certified packages are allowed by group policy or configuration.
As part of this change, and to comply with the certified installer requirements, the Setup.exe versions of the MySQL installer have been discontinued. You must have Windows Installer support in your Windows installation to use the MSI install package. This is a standard component on Windows XP SP2 and higher. For earlier versions, you can download the Microsoft Installer support from Microsoft.com. (Bug#36409)
Changing the transaction isolation level while replicating
InnoDB tables could cause
statement-based logging to fail.
A comparison with an invalid
DATE value in a
query against a partitioned table could lead to a crash of the
DATETIME values referenced in the
WHERE clause of a query on a partitioned
table are treated as
Section 18.4, “Partition Pruning”, for more information.
Partitioning: A query on a user-partitioned table caused MySQL to crash, where the query had the following characteristics:
WHERE clause referenced
an indexed column that was also in the partitioning key.
WHERE clause included a
value found in the partition.
WHERE clause used the
operators to compare with the indexed column's value
with a constant.
The query used an
ORDER BY clause, and
the same indexed column was used in the
ORDER BY clause used an explcit or
ASC sort priority.
Two examples of such a query are given here, where
a represents an indexed column used in the
table's partitioning key:
SELECT * FROM
tableWHERE a <
constantORDER BY a;
SELECT * FROM
tableWHERE a <>
constantORDER BY a;
This bug was introduced in MySQL 5.1.29. (Bug#40954)
transaction isolation level,
uses a semi-consistent read that releases nonmatching rows after
MySQL has evaluated the
However, this was not happening if the table used partitions.
Partitioning: A query that timed out when run against a partitioned table failed silently, without providing any warnings or errors, rather than returning Lock wait timeout exceeded. (Bug#40515)
ALTER TABLE ... REORGANIZE PARTITION could
crash the server when the number of partitions was not changed.
See also Bug#41945.
For a partitioned table having an
AUTO_INCREMENT column: If the first statement
following a start of the server or a
TABLES statement was an
AUTO_INCREMENT column was not
The server attempted to execute the statements
TABLE ... ANALYZE PARTITION,
ALTER TABLE ...
ALTER TABLE ... OPTIMIZE
ALTER TABLE ... REORGANIZE
PARTITION on tables that were not partitioned.
See also Bug#20129.
When executing an
ORDER BY query on a
InnoDB table using an index that
was not in the partition expression, the results were sorted on
a per-partition basis rather than for the table as a whole.
Dropping or creating an index on a partitioned table managed by
InnoDB Plugin locked the table.
Partitioning: Partitioned table checking sometimes returned a warning with an error code of 0, making proper response to errors impossible. The fix also renders the error message subject to translation in non-English deployments. (Bug#36768)
SHOW TABLE STATUS could show a nonzero value
Mean record length of a partitioned
InnoDB table, even if the table
contained no rows.
SHOW CREATE TABLE was used on a
partitioned table, all of the table's
clauses were output on a single line, making it difficult to
read or parse.
AUTO_INCREMENT option values were
not replicated correctly for
log_event types did not skip the
post-header when reading.
Attempting to read a binary log containing an
Incident_log_event having an invalid incident
number could cause the debug server to crash.
Replication: When using row-based replication, an update of a primary key that was rolled back on the master due to a duplicate key error was not rolled back on the slave. (Bug#40221)
Replication: When rotating relay log files, the slave deletes relay log files and then edits the relay log index file. Formerly, if the slave shut down unexpectedly between these two events, the relay log index file could then reference relay logs that no longer existed. Depending on the circumstances, this could when restarting the slave cause either a race condition or the failure of replication. (Bug#38826, Bug#39325)
With row-based replication,
DELETE statements using
LIMIT and a table's primary key could
produce different results on the master and slave.
The optimizer could ignore an error and rollback request during a filesort, causing an assertion failure. (Bug#41543)
When a repair operation was carried out on a
CSV table, the debug server
When substituting system constant functions with a constant
result, the server was not expecting
function return values and could crash.
INSERT INTO .. SELECT
... FROM and
CREATE TABLE ...
SELECT ... FROM a TEMPORARY table could inadvertently
change the locking type of the temporary table from a write lock
to a read lock, causing statement failure.
In debug builds, obsolete debug code could be used to crash the server. (Bug#41041)
Some queries that used a “range checked for each record” scan could return incorrect results. (Bug#40974)
See also Bug#44810.
Accessing user variables within triggers could cause a server crash. (Bug#40770)
IF(..., CAST( as
an argument to an aggregate function could cause an assertion
statements, an assertion failure resulted from a runtime error
in a stored function (such as a recursive function call or an
attempt to update the same table as in the
mc.exe is no longer needed to compile MySQL on Windows. This makes it possible to build MySQL from source using Visual Studio Express 2008. (Bug#40280)
':' character was incorrectly disallowed
in table names.
Retrieval speed from the following
INFORMATION_SCHEMA tables was improved by
VARIABLE_VALUE column to 1024
If the operating system is configured to return leap seconds
from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as
NOW() could return a value having
a time part that ends with
:59:61. If such values are inserted into a
table, they would be dumped as is by
mysqldump but considered invalid when
reloaded, leading to backup/restore problems.
Now leap second values are returned with a time part that ends
:59:59. This means that a function such
NOW() can return the same
value for two or three consecutive seconds during the leap
second. It remains true that literal temporal values having a
time part that ends with
:59:61 are considered invalid.
The server could crash during a sort-order optimization of a dependent subquery. (Bug#39844)
SQL mode enabled, the check for nonaggregated columns in queries
with aggregate functions, but without a
BY clause was treating all the parts of the query as
if they were in the select list. This is fixed by ignoring the
nonaggregated columns in the
The server crashed if an integer field in a CSV file did not have delimiting quotes. (Bug#39616)
Creating a table with a comment of 62 characters or longer caused a server crash. (Bug#39591)
The do_abi_check program run during the build
process depends on
mysql_version.h but that
file was not created first, resulting in build failure.
InnoDB could hang trying to open an adaptive
TABLE ... DISCARD TABLESPACE for an
InnoDB table, an attempt to determine the
free space for the table before the
TABLE operation had completely finished could cause a
The server returned a column type of
VARBINARY rather than
DATE as the result from the
LEAST() functions or
CASE expression if the result was
filesort in an anonymous
temporary table during the query execution.
A server built using yaSSL for SSL support would crash if configured to use an RSA key and a client sent a cipher list containing a non-RSA key as acceptable. (Bug#39178)
When built with Valgrind, the server failed to access tables
created with the
DATA DIRECTORY or
INDEX DIRECTORY table option.
The fast mutex implementation was subject to excessive lock contention. (Bug#38941)
On Windows, a five-second delay occurred at shutdown of applications that used the embedded server. (Bug#38522)
On Solaris, a scheduling policy applied to the main server process could be unintentionally overwritten in client-servicing threads. (Bug#38477)
Building MySQL on FreeBSD would result in a failure during the gen_lex_hash phase of the build. (Bug#38364)
ExtractValue() function did not work
correctly with XML documents containing a
Queries with a
HAVING clause could return a
The Event Scheduler no longer logs “started in thread” or “executed” successfully messages to the error log. (Bug#38066)
An error in a debugging check caused crashes in debug servers. (Bug#37936)
The presence of a
/* ... */ comment preceding
a query could cause
InnoDB to use unnecessary
Primary keys were treated as part of a covering index even if only a prefix of a key column was used. (Bug#37742)
ARCHIVE table to the
same name with different lettercase and then selecting from it
could cause a server crash.
DAYNAME() functions returned a
binary string, so that using
UPPER() had no effect. Now
DAYNAME() return a value in
See also Bug#42525.
TABLES to get the list of tables in a database. For
some problems, such as an empty
for a table, this would fail and mysqlcheck
then would neglect to check other tables in the database.
Updating a view with a subquery in the
option could cause an assertion failure.
Statements that displayed the value of system variables (for
SHOW VARIABLES) expect
variable values to be encoded in
variables set from the command line such as
datadir were encoded using
not converted correctly.
FULLTEXT searches that
used the truncation operator did not return matching records and
calculated relevance incorrectly.
On a 32-bit server built without big tables support, the offset
argument in a
LIMIT clause might be truncated
due to a 64-bit to 32-bit cast.
InnoDB table with a
TABLE may be performed using row by row deletion. If
an error occurred during this deletion, the table would be only
partially emptied. Now if an error occurs, the truncation
operation is rolled back and the table is left unchanged.
The code for the
ut_usectime() function in
InnoDB did not handle errors from the
gettimeofday() system call. Now it retries
gettimeofday() several times and updates
the value of the
status variable only if
For upgrades to MySQL 5.1 or higher,
mysql_upgrade did not re-encode database or
table names that contained nonalphanumeric characters. (They
would still appear after the upgrade with the
#mysql50# prefix described in
Section 8.2.3, “Mapping of Identifiers to File Names”.) To correct this problem,
it was necessary to run mysqlcheck --all-databases
--check-upgrade --fix-db-names --fix-table-names
manually. mysql_upgrade now runs that command
automatically after performing the initial upgrade.
The columns that store character set and collation names in
INFORMATION_SCHEMA tables were
lengthened because they were not long enough to store some
Selecting from an
into an incorrectly defined
table caused an assertion failure.
The mysql client incorrectly parsed statements containing the word “delimiter” in mid-statement.
This fix is different from the one applied for this bug in MySQL 5.1.26. (Bug#33812)
See also Bug#38158.
For a stored procedure containing a
SELECT * ... RIGHT
JOIN query, execution failed for the second call.
Previously, use of index hints with views (which do not have indexes) produced the error ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR 1176 (HY000): Key '...' doesn't exist in table '...', the same error as for base tables without an appropriate index. (Bug#33461)
Three conditions were discovered that could cause an upgrade
from MySQL 5.0 to 5.1 to fail: 1) Triggers associated with a
table that had a
#mysql50# prefix in the name
could cause assertion failure. 2)
... UPGRADE DATA DIRECTORY NAME failed for databases
that had a
#mysql50# prefix if there were
triggers in the database. 3) mysqlcheck
--fix-table-name didn't use UTF8 as the default
character set, resulting in parsing errors for tables with
nonlatin symbols in their names and trigger definitions.
Execution of a prepared statement that referred to a system variable caused a server crash. (Bug#32124)
Some division operations produced a result with incorrect precision. (Bug#31616)
Server variables could not be set to their current values on Linux platforms. (Bug#31177)
See also Bug#6958.
For installation on Solaris using pkgadd
packages, the mysql_install_db script was
generated in the
scripts directory, but the
temporary files used during the process were left there and not
SHOW statements and
retrievals from the
EVENTS tables used a temporary
table and incremented the
variable, due to the way that
are handled. The
EVENTS.SQL_MODE columns now are
VARCHAR to avoid this problem.
For several read only system variables that were viewable with
SHOW VARIABLES, attempting to
view them with
@@ or set their
SET resulted in an
unknown system variable error. Now they can
be viewed with
@@ and attempting
to set their values results in a message indicating that they
are read only.
SSL support was not included in some “generic” RPM packages. (Bug#26760)
See also Bug#32223.
On Windows, moving an
.ibd file and then symlinking to it in the
database directory using a
.sym file caused
a server crash.