Functionality Added or Changed
packages are now available. These client library compatibility
packages are like the
package, but are for the “MySQL Enterprise Server —
Advanced Edition” products. Install these packages rather
than the normal
if you want to included shared client libraries for older MySQL
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.
SELECT * retrievals from
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 have
changed. Previously, if the initial statements in a transaction
contained nontransactional changes, those statements were
written directly to the binary log. Now, any statement appearing
(or 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.
See Replication and Transactions, for more information about this change in behavior. (Bug #40116)
Important Change: The MSI installer packages for Windows are now digitally signed with a certificate, enabling installation on Windows where only certified packages are permitted 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
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 explicit 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)
References: This bug was introduced by Bug #30573, Bug #33257, Bug #33555.
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.
References: 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.
References: See also Bug #20129.
The value of the
CREATE_COLUMNS column in
INFORMATION_SCHEMA.TABLES was not
partitioned for partitioned tables.
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.
resolve_stack_dump was unable to resolve the stack trace format produced by mysqld in MySQL 5.1 and up (see Using a Stack Trace). (Bug #41612)
In example option files provided in MySQL distributions, the
thread_stack value was
increased from 64K to 128K.
The optimizer could ignore an error and rollback request during a filesort, causing an assertion failure. (Bug #41543)
DATE_FORMAT() could cause a
server crash for year-zero dates.
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.
Queries such as
SELECT ... CASE AVG(...) WHEN
... that used aggregate functions in a
CASE expression crashed the server.
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.
table was limited to 7680 rows.
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)
References: See also Bug #44810.
SELECT queries could fail
Duplicate entry error.
For debug servers,
on a compressed table caused a server crash.
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
When executing concurrent
CREATE TABLE ...
SELECT statements on a
Error: Memory allocated at trnman.c:129 was
underrun, discovered at ma_close.c:65 error would be
logged in the error file, and the server would eventually crash.
TRUNCATE TABLE for an
InnoDB table did not flush cached queries for
Prepared statements permitted invalid dates to be inserted when
mode was not enabled.
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 not
permitted in table names.
Support for the
revision field in
.frm files has been removed. This addresses
the downgrading problem introduced by the fix for Bug #17823.
Retrieval speed from the following
INFORMATION_SCHEMA tables was improved by
VARIABLE_VALUE column to 1024
As a result of this change, any variable value longer than 1024
characters will be truncated with a warning. This affects only
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.
For additional details about leap-second handling, see Time Zone Leap Second Support. (Bug #39920)
The server could crash during a sort-order optimization of a dependent subquery. (Bug #39844)
For a server started with the
--temp-pool option on Windows,
temporary file creation could fail. This option now is ignored
except on Linux systems, which was its original intended scope.
ALTER TABLE on a table with
FULLTEXT index that used a pluggable
FULLTEXT parser could cause debug servers to
INSERT on a
Maria table with a
column, MySQL could deadlock.
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 quotation marks. (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.
On 64-bit Windows systems, the server accepted
key_buffer_size values larger
than 4GB, but allocated less. (For example, specifying a value
of 5GB resulted in 1GB being allocated.)
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
Use of the
MAX_ROWS table option in
ALTER TABLE should have triggered
table reconstruction but did not.
Multiple concurrent inserts to a
could lead to a deadlock situation.
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.
Maria could fail to find data in a table with
an index on a
ALTER TABLE PARTITION on a
Maria table would lead to a crash.
WITH READ LOCK after a
statement would lead to a crash.
DELETE queries on the
Maria table could lead to a deadlock.
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.
With binary logging enabled
VIEW was subject to possible buffer overwrite and a
The fast mutex implementation was subject to excessive lock contention. (Bug #38941)
SHOW ENGINE INNODB
STATUS or one of the
InnoDB Monitor tables) could cause
a server crash due to invalid access to a shared variable in a
InnoDB could fail to generate
AUTO_INCREMENT values after an
UPDATE statement for the table.
If delayed insert failed to upgrade the lock, it did not free
the temporary memory storage used to keep newly constructed
BLOB values in memory, resulting
in a memory leak.
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)
On Windows, the embedded server would crash in
mysql_library_init() if the
language file was missing.
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)
Use of spatial data types in prepared statements could cause memory leaks or server crashes. (Bug #37956, Bug #37671)
An error in a debugging check caused crashes in debug servers. (Bug #37936)
SELECT with a
IN condition containing a complex subquery from the
same table as in the outer select caused an assertion failure.
The presence of a
/* ... */ comment preceding
a query could cause
InnoDB to use unnecessary
Use of an uninitialized constant in
EXPLAIN evaluation caused an
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
References: See also Bug #42525.
SHOW PROCESSLIST displayed
“copy to tmp table” when no such copy was
TABLES to get the list of tables in a database. For
some problems, such as an empty
for a table, this failed 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.
CREATE INDEX could crash with
InnoDB plugin 1.0.1.
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
The mysql client, when built with Visual Studio 2005, did not display Japanese characters. (Bug #36279)
CREATE INDEX for
InnoDB tables could under very rare
circumstances cause the server to crash..
A read past the end of the string could occur while parsing the
value of the
system variable to
DEFAULT failed in the
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
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
max_length metadata value was calculated
incorrectly for the
function, which could cause incorrect result set metadata to be
sent to clients.
InnoDB could fail to generate
AUTO_INCREMENT values if rows previously had
been inserted containing literal values for the
(Bug #35498, Bug #36411, Bug #39830)
CREATE_OPTIONS column for
INFORMATION_SCHEMA.TABLES did not
Selecting from an
into an incorrectly defined
table caused an assertion failure.
perror on Windows did not know about Win32 system error codes. (Bug #34825)
EXPLAIN EXTENDED evaluation of
aggregate functions that required a temporary table caused a
STATUS shows values that aggregate the session status
values for all threads. This did not work correctly for the
mysqldumpslow did not aggregate times. (Bug #34129)
mysql_config did not output
-ldl (or equivalent) when needed for
--libmysqld-libs, so its
output could be insufficient to build applications that use the
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)
References: 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 did not use
as the default character set, resulting in parsing errors for
tables with nonlatin symbols in their names and trigger
(Bug #33094, Bug #41385)
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)
Queries executed using join buffering of
BIT columns could produce
Server variables could not be set to their current values on Linux platforms. (Bug #31177)
References: 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)
Questions status variable
is intended as a count of statements sent by clients to the
server, but was also counting statements executed within stored
References: See also Bug #32223.
A race condition between the mysqld.exe server and the Windows service manager could lead to inability to stop the server from the service manager. (Bug #20430)
On Windows, moving an
.ibd file and then symlinking to it in the
database directory using a
.sym file caused
a server crash.