This release of MySQL has two known outstanding issues for Windows:
.msi installer does not detect an
root password on the initial
configuration attempt. To work around this, install and
configure MySQL as normal, but skip any changes to security.
(There is a checkbox that allows this on the security screen
of the configuration wizard.) Then check your settings:
If the old
root password and security
settings are okay, you are done and can proceed to use
Otherwise, reconfigure with the wizard and make any
changes on the second configuration attempt. The wizard
will properly prompt for the existing
root password and allow changes to be
This issue has been filed as Bug#45200 for correction in a future release.
The Windows configuration wizard allows changes to
InnoDB settings during a reconfiguration
operation. For an upgrade, this may cause difficulties. To
work around this, use one of the following alternatives:
Do not change
Copy files from the old
location to the new one.
This issue has been filed as Bug#45201 for correction in a future release.
InnoDB uses random numbers to
generate dives into indexes for calculating index cardinality.
However, under certain conditions, the algorithm did not
generate random numbers, so
TABLE did not update cardinality estimates properly. A
new algorithm has been introduced with better randomization
properties, together with a system variable,
that controls which algorithm to use. The default value of the
variable is 1 (
ON), to use the original
algorithm for compatibility with existing applications. The
variable can be set to 0 (
OFF) to use the new
algorithm with improved randomness.
If the character set for a column being compared was neither the
default server character set nor
InnoDB was slower than necessary due to
excessive contention for a character set mutex.
As a workaround for earlier versions, set the default server
character set to the character set other than
latin1 that is most often used in indexed
Important Change: Replication:
The transactional behavior of
SLAVE has changed. Formerly, it took effect
immediately, even inside a transaction; now, it waits until the
current replication event group (if any) has finished executing,
or until the user issues a
KILL QUERY or
This was done in order to solve the problem encountered when
replication was stopped while a nontransactional slave was
replicating a transaction on the master. (It was impossible to
roll back a mixed-engines transaction when one of the engines
was nontransactional, which meant that the slave could not
safely re-apply any transaction that had been interrupted by
See also Bug#43217.
When a value was equal to a
PARTITION ... VALUES LESS
THAN ( value other
MAXVALUE, the corresponding partition
was not pruned.
Replication: The following errors were not correctly reported:
Failures during slave thread initialization
Failures while initializing the relay log position (immediately following the starting of the slave thread)
Failures while processing queries passed through the
Replication: Killing the thread executing a DDL statement, after it had finished its execution but before it had written the binlog event, caused the error code in the binlog event to be set (incorrectly) to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED, which caused replication to fail. (Bug#37145)
Replication: Column aliases used inside subqueries were ignored in the binary log. (Bug#35515)
On Windows, entries for build-vs9.bat and
build-vs9_x64.bat were missing in
Incomplete cleanup of
the filesort of rows for a
GROUP BY clause
inside a subquery caused a server crash.
MySQL Server allowed the creation of a merge table based on views but crashed when attempts were made to read from that table. The following example demonstrates this:
#Create a test table CREATE TABLE tmp (id int, c char(2)); #Create two VIEWs upon it CREATE VIEW v1 AS SELECT * FROM tmp; CREATE VIEW v2 AS SELECT * FROM tmp; #Finally create a MERGE table upon the VIEWs CREATE TABLE merge (id int, c char(2)) ENGINE=MERGE UNION(v1, v2); #Reading from the merge table lead to a crash SELECT * FROM merge;
The final line of the code generated the crash. (Bug#44040)
Some schema names longer than 8 characters were not supported by
IBMDB2I. The engine has been updated to allow
digits and underscore characters to be used in names longer than
In some circumstances, when a table is created with the
IBMDB2I engine, the
TABLE statement will return successfully but the table
will not exist.
utf8_swedish_ci collations did not work with
indexes using the
IBMDB2I storage engine.
Support is now provided for MySQL when running on IBM i 6.1 or
Incorrect initialization of
indexes could cause incorrect query results.
Certain statements might open a table and then wait for an
impending global read lock without noticing whether they hold a
table being waiting for by the global read lock, causing a hang.
Affected statements are
SELECT ... FOR
LOCK TABLES ...
Using an XML function such as
more than once in a single query could produce erroneous
See also Bug#43937.
Full-text prefix searches could hang the connection and cause 100% CPU consumption. (Bug#42907)
Incorrect elevation of warning messages to error messages for unsafe statements caused a server crash. (Bug#42640)
MyISAM table with
DELAY_KEY_WRITE enabled, the index file could
be corrupted without the table being marked as crashed if the
server was killed.
For some queries, an equality propagation problem could cause
a = b and
b = a to be
A stored routine contain a C-style comment could not be dumped and reloaded. (Bug#39559)
The functions listed in Section 126.96.36.199.3, “Creating Geometry Values Using MySQL-Specific Functions”, previously accepted WKB arguments and returned WKB values. They now accept WKB or geometry arguments and return geometry values.
The functions listed in Section 188.8.131.52.2, “Creating Geometry Values Using WKB Functions”, previously accepted WKB arguments and returned geometry values. They now accept WKB or geometry arguments and return geometry values. (Bug#38990)
For shared-memory connections, the read and write methods did
not properly handle asynchronous close events, which could lead
to the client locking up waiting for a server response. For
example, a call to
mysql_real_query() would block
forever on the client side if the executed statement was aborted
on the server side. Thanks to Armin Schöffmann for the bug
report and patch.
InnoDB tables that have their own
.ibd tablespace file, a superfluous
ibuf cursor restoration fails! message could
be written to the error log. This warning has been suppressed.
Several memory allocation functions were not being checked for out-of-memory return values. (Bug#25058)