Functionality Added or Changed
CHAR() function now takes
into account the character set and collation given by the
variables. For an argument
CHAR(), the result is
n mod 256 for single-byte character
sets. For multibyte character sets,
n must be a valid code point in the
character set. Also, the result string from
CHAR() is checked for
well-formedness. For invalid arguments, or a result that is not
well-formed, MySQL generates a warning (or, in strict SQL mode,
--delayed-insert option for
mysqldump, which now checks for each table
dumped whether its storage engine supports
Configure-time checking for the availability of multibyte
macros and functions in the bundled
library. This improves handling of multibyte character sets in
the mysql client.
which controls whether
NULL values in indexes
are considered the same or different when collecting statistics
MyISAM tables. This influences the query
optimizer as described in
MyISAM Index Statistics Collection.
The limit of 255 characters on the input buffer for mysql on Windows has been lifted. The exact limit depends on what the system permits, but can be up to 64KB characters. A typical limit is 16KB characters. (Bug #12929)
InnoDB foreign key constraint is
violated, the error message now indicates which table, column,
and constraint names are involved.
Range scans can now be performed for queries on VIEWs such as
column IN (<constants>) and
column BETWEEN ConstantA AND ConstantB.
RENAME TABLE now works for views
as well, as long as you do not try to rename a view into a
Receipt of several
ENTER SINGLE USER MODE
commands by multiple ndb_mgmd processes
within a short period of time resulted in cluster shutdown.
With two mgmd processes in a cluster,
ndb_mgm output for
SHOW would display the same IP
address for both processes, even when they were on different
MySQL Cluster: Adding an index to a table with a large number of columns (more then 100) crashed the storage node. (Bug #13316)
A trigger updating the value of an
AUTO_INCREMENT column in an
NDB table would insert an error
code rather than the expected value into the column.
MySQL Cluster: Multiple ndb_mgmd processes in a cluster did not know each other's IP addresses. (Bug #12037)
MySQL Cluster: If ndb_restore could not find a free mysqld process, it crashed. (Bug #13512)
INFILE with a large data file failed.
When deleting a great many (tens of thousands of) rows at once
NDB table, an improperly
dereferenced pointer could cause the mysqld
process to crash.
The optimizer chose a less efficient execution plan for
ref access method for
HAVING clause that references an
unqualified view column name could crash the server.
After running configure with the
--without-server option, the
distribution failed to build.
(Bug #11680, Bug #13550)
CHECKSUM TABLE locked
InnoDB tables and did not use a consistent
For queries with
DISTINCT should be
applied after the rollup operation, but was not always.
NATURAL joins and joins with
USING against a view could return
NULL rather than the correct value.
Shared-memory connections were not working on Windows. (Bug #12723)
Queries against a
MERGE table that has a
composite index could produce incorrect results.
Nested handlers within stored procedures didn't work. (Bug #6127)
Joins nested under
USING joins were sometimes not initialized
properly, causing a server crash.
SELECT ... FOR
SELECT ... LOCK IN SHARE
MODE for an
InnoDB table were
executed from within a stored function or a trigger, they were
converted to a nonlocking consistent read.
It was possible to create a view that executed a stored function
for which you did not have the
The server was not rejecting
columns specifications when
Use of a user-defined function within the
HAVING clause of a query resulted in an
Unknown column error.
Locking a view with the query cache enabled and
enabled could cause a server crash.
After running configure with the
--with-embedded-privilege-control option, the
embedded server failed to build.
For queries for which the optimizer determined a join type of
“Range checked for each record” (as shown by
EXPLAIN, the query sometimes
could cause a server crash, depending on the data distribution.
Comparisons involving row constructors containing constants could cause a server crash. (Bug #13356)
The server crashed when processing a view that invoked the
--skip-innodb-doublewrite option disables
use of the
InnoDB doublewrite buffer.
However, having this option in effect when creating a new MySQL
installation prevented the buffer from even being created,
resulting in a server crash later.
Incorrect creation of
local variables in a stored procedure could cause a server
MySQL programs in binary distributions for Solaris 8/9/10 x86 systems would not run on Pentium III machines. (Bug #6772)
Certain joins using
Range checked for each
record in the query execution plan could cause the
server to crash.