This is the final release of MySQL 5.5 for which Generic Linux MySQL binary packages built with the icc compiler on x86 and x86_64 will be offered. These were previously produced as an alternative to our main packages built using gcc, as they provided noticeable performance benefits. In recent times the performance differences have diminished and build and runtime problems have surfaced, thus it is no longer viable to continue producing them.
We continue to use the icc compiler to produce our distribution-specific RPM packages on ia64.
InnoDB has been upgraded to version 1.1.1.
This version is considered of “early adopter”
InnoDB is now the default storage engine,
MyISAM, in the regular and
enterprise versions of MySQL. This change has the following
Existing tables are not affected by this change, only new tables that are created.
Some of the
InnoDB option settings also
change, so that the default configuration represents the
best practices for
reliability, and file management:
The system tables remain in
MyISAM remains the default storage engine
for the embedded version of MySQL.
Follow these steps to ensure a smooth transition when upgrading:
Familiarize yourself with the new default setting for the
InnoDB file-per-table option, which
creates a separate
.ibd file for each
user table. Adapt any backup procedure to include these
files. For details, see
InnoDB File-Per-Table Tablespaces.
Test the installation and operation for any applications
that you run on the database server, to determine if they
use any features specific to
cause problems during installation (when the tables are
created) or at runtime (when
MyISAM-specific features might fail, or
MyISAM settings for
performance might become apparent). The
InnoDB “strict” mode might
also alert you to problems while setting up tables for an
As a preliminary test for individual tables rather than an
entire application, you can use the statement
TABLE to convert an existing table to use
InnoDB storage engine, and then run
compatibility and performance tests.
Where necessary, add
statements, for tables that require features specific to
MyISAM, such as full-text search.
Benchmark the most important queries, to check whether you need to make changes to the table indexes.
Measure the performance of applications under typical load,
to check whether you need to change any additional
InnoDB configuration settings.
As a last resort, if a database server is devoted entirely
to applications that can only run with
MyISAM tables, you could add a
in the configuration file, or a
option in the database server startup command, to re-enable
MyISAM as the default storage engine for
that server. For details about setting the default storage
engine, see Setting the Storage Engine.
Functionality Added or Changed
All numeric operators and functions on integer, floating-point
DECIMAL values now throw an
“out of range” error
than returning an incorrect value or
when the result is out of the supported range for the
corresponding data type. See
Out-of-Range and Overflow Handling.
table now includes a number of fields that duplicate information
ENGINE INNODB STATUS output. You no longer need to
parse that output to get complete transaction information.
InnoDB stores redo log records in a
hash table during recovery. On 64-bit systems, this hash table
was 1/8 of the buffer pool size. To reduce memory usage, the
dimension of the hash table was reduced to 1/64 of the buffer
pool size (or 1/128 on 32-bit systems).
variable served a dual purpose. Setting it at server startup
InnoDB from starting if any tables
used a more recent file format than supported by the current
could start, the same system variable was set to the
“highest” file format value used by any
InnoDB table in the database. Thus, its value
could change from the value you specified.
Now, checking and recording the file format tag are handled
using separate variables.
innodb_file_format_check can be
set to 1 or 0 at server startup to enable or disable whether
InnoDB checks the file format tag in the
system tablespace. If the tag is checked and is higher than that
supported by the current version of
an error occurs and
InnoDB does not start. If
the tag is not higher,
InnoDB sets the value
the file format tag.
For background information about
file-format management, see
InnoDB File-Format Management.
(Bug #49792, Bug #53654)
For events of
event subclass was not passed to audit plugins even though the
server passed the subclass to the plugin handler. The subclass
is now available through the following changes:
struct mysql_event_general structure
has a new
The new member changes the interface, so the audit plugin
MYSQL_AUDIT_INTERFACE_VERSION, has been
0x0200. Plugins that require access to
the new member must be recompiled to use version
0x0200 or higher.
NULL_AUDIT example plugin in the
plugin/audit_null directory has been
modified to count events of each subclass, based on the
event_subclass value. See
Writing Audit Plugins.
The deprecated mysql_fix_privilege_tables script has been removed. (Bug #42589)
A new system variable,
skip_name_resolve, is set from
the value of the
option. This provides a way to determine at runtime whether the
server uses name resolution for client connections.
SHA2() function, which
calculates the SHA-2 family of hash functions (SHA-224, SHA-256,
SHA-384, and SHA-512). (Contributed by Bill Karwin)
It is now possible to build MySQL on all platforms using CMake instead of the GNU autotools. (Prior to MySQL 5.5.5, CMake support was limited to Windows.) For instructions on using CMake to build MySQL, see Installing MySQL from Source.
Windows MSI package installers create and set up the data
directory that the installed server will use, but now also
create a pristine “template” data directory named
data under the installation directory. This
directory can be useful when the machine will be used to run
multiple instances of MySQL: After an installation has been
performed using an MSI package, the template data directory can
be copied to set up additional MySQL instances. See
Running Multiple MySQL Instances on One Machine.
The server could crash if there were alternate reads from two
indexes on a table using the
(Bug #54007, CVE-2010-3681)
Security Fix: A security bug was fixed. (Bug #53933)
Security Fix: A security bug was fixed. (Bug #53907)
The server failed to check the table name argument of a
COM_FIELD_LIST command packet for validity
and compliance to acceptable table name standards. This could be
exploited to bypass almost all forms of checks for privileges
and table-level grants by providing a specially crafted table
name argument to
In MySQL 5.0 and above, this permitted an authenticated user
SELECT privileges on one
table to obtain the field definitions of any table in all other
databases and potentially of other MySQL instances accessible
from the server's file system.
Additionally, for MySQL version 5.1 and above, an authenticated
SELECT privileges on one table
could delete or read content from any other table in all
databases on this server, and potentially of other MySQL
instances accessible from the server's file system.
(Bug #53371, CVE-2010-1848)
The server was susceptible to a buffer-overflow attack due to a
failure to perform bounds checking on the table name argument of
COM_FIELD_LIST command packet. By sending
long data for the table name, a buffer is overflown, which could
be exploited by an authenticated user to inject malicious code.
(Bug #53237, CVE-2010-1850)
INFILE did not check for SQL errors and sent an OK
packet even when errors were already reported. Also, an assert
related to client/server protocol checking in debug servers
sometimes was raised when it should not have been.
(Bug #52512, CVE-2010-3683)
Security Fix: A security bug was fixed. (Bug #52357)
Security Fix: A security bug was fixed. (Bug #52315)
Privilege checking for
PLUGIN was incorrect.
(Bug #51770, CVE-2010-1621)
Security Fix: The server could be tricked into reading packets indefinitely if it received a packet larger than the maximum size of one packet. (Bug #50974, CVE-2010-1849)
Security Fix: A security bug was fixed. (Bug #48157)
Deadlock detection could be a bottleneck in
InnoDB processing, if many
transactions attempted to update the same row simultaneously.
The algorithm has been improved to enhance performance and
scalability, in the InnoDB Plugin for MySQL 5.1, and in InnoDB
1.1 for MySQL 5.5.
While looking for the shortest index for a covering index scan,
the optimizer did not consider the full row length for a
clustered primary key, as in
InnoDB. Secondary covering indexes
are now preferred, making full table scans less likely.
References: See also Bug #55656.
TRUNCATE TABLE did not take an
exclusive lock on a table if truncation was done by deleting all
rows in the table. For
InnoDB tables, this
could break proper isolation because
ended up aborting some granted locks when truncating a table.
Now an exclusive metadata lock is taken before
TRUNCATE TABLE can proceed. This
guarantees that no other transaction is using the table.
Incompatible change: Truncation using delete no longer fails if
sql_safe_updates is enabled
(this was an undocumented side effect).
TRANSACTION ISOLATION LEVEL to set the isolation level
for the next transaction, the session value of the
tx_isolation system variable
could appear to change to the transaction isolation level after
completion of statements within the transaction. Now the current
transaction isolation level is now established at transaction
start. If there was a
ISOLATION LEVEL statement, the value is taken from it.
Otherwise, the session
tx_isolation value is used. A
change in the session value while a transaction is active is
still permitted, but no longer affects the current transaction
isolation level. This is an incompatible change. A change in the
session isolation level made while there is no active
transaction overrides a
ISOLATION LEVEL statement, if there was any.
Important Change; Replication:
It was possible to set
sql_log_bin with session scope
inside a transaction or subquery.
Important Change; Replication:
permissions were not checked prior to checking the scope and
context of the variable being changed.
As a result of this fix, an error is no longer reported when—in the context of a transaction or a stored function—you try to set a value for a session variable that is the same as its previous value, or for a variable whose scope is global only. (Bug #51277)
Important Change; Replication:
CHANGE MASTER TO
sql_slave_skip_counter now cause information to be
written to the error log about the slave's state prior to
execution of the statement. For
MASTER TO, this information includes the previous
GLOBAL sql_slave_skip_counter, this information
includes the previous values of
(Bug #43406, Bug #43407)
When using fast
different internal ordering of indexes in the MySQL optimizer
InnoDB storage engine could
cause error messages about possibly mixed up
.frm files and incorrect index use.
Reading from a table that used a self-logging storage engine and
updating a table that used a transactional engine (such as
InnoDB) generated changes that were written
to the binary log using statement format which could make slaves
diverge. However, when using mixed logging format, such changes
should be written to the binary log using row format. (This
issue did not occur when reading from tables using a
self-logging engine and updating
tables, as this was already handled by checking for combinations
of nontransactional and transactional engines.) Now such
statements are classified as unsafe, and in mixed mode, cause a
switch to row-based logging.
The server could crash with a message
failure in thread ,
typically during shutdown on a Windows system.
Some combinations of
SELECT FOR UPDATE statements could fail with
errors about locks, or incorrectly release a row lock during a
Adding a unique key on multiple columns, where one of the
NULL, could mistakenly report
duplicate key errors.
Fixed a checksum error reported for compressed tables when the
--innodb_checksums option is enabled.
Although the message stated that the table was corrupted, the
table is actually fine.
The values of
innodb_buffer_pool_pages_misc in the
information_schema.global_status table could
be computed incorrectly.
InnoDB page splitting could enter
an infinite loop for compressed tables.
An overly strict assertion could fail during the purge of
delete-marked records in
InnoDB tables that contain column
InnoDB attempted to choose off-page
storage without ensuring that there was an “off-page
storage” flag in the record header. To correct this, in
InnoDB stores locally any
BLOB columns having a maximum
length not exceeding 256 bytes. This is because there is no room
for the “external storage” flag when the maximum
length is 255 bytes or less. This restriction trivially holds in
formats, because there
always stores locally columns having a length up to
local_len = 788 bytes.
The server could crash during shutdown, if started with the
Connections waiting for an
InnoDB row lock
KILL until the row lock
wait ended. Now,
KILL during lock
wait results in “query interrupted” instead of
“lock wait timeout exceeded”. The corresponding
transaction is rolled back.
InnoDB checks to see whether a row could
possibly exceed the maximum size if all columns are fully used.
Row size too large errors for
some tables that could be created with the built-in
InnoDB from older MySQL versions. Now the
check is only done when
innodb_strict_mode is enabled
or if the table is dynamic or compressed.
Multi-statement execution could fail with an error about foreign
key constraints. This problem could affect calls to
CALL statements that invoke stored
A mismatch between index information maintained within the
.frm files and the corresponding information
in the InnoDB system tablespace could produce this error:
n columns unique inside InnoDB, but
MySQL is asking statistics for
columns. Have you mixed up .frm files from different
Attempting to execute
on a partitioned
MyISAM table while using
statement-based logging mode caused the master to hang or crash.
SQL mode was not enforced when defining subpartitions. In
certain cases, this could lead to failures on replication
Rows inserted into a table created using a
LIST COLUMNS option referencing multiple columns could
be inserted into the wrong partition.
Partition pruning on
RANGE partitioned tables
did not always work correctly; the last partition was not
excluded if the range was beyond it (when not using
MAXVALUE). Now the last partition is not
included if the partitioning function value is not within the
Attempting to partition a table using a
DECIMAL column caused the server
to crash; this was not supported and is now specifically not
TABLE statements that cause table partitions to be
renamed or dropped (such as
ALTER TABLE ... ADD
ALTER TABLE ... DROP
ALTER TABLE ... REORGANIZE
PARTITION) — when run concurrently with queries
— could fail, cause the affected partitioned tables to
become unusable, or both. This was due to the fact that the
INFORMATION_SCHEMA database ignored the name
lock imposed by the
statement on the partitions affected. In particular, this led to
InnoDB would accept the
rename operation, but put it in a background queue, so that
subsequent rename operations failed when
InnoDB was unable to find the
correct partition. Now,
honors name locks imposed by ongoing
TABLE statements that cause partitions to be renamed
References: See also Bug #47343, Bug #45808.
Foreign keys are not supported on partitioned tables. However,
it was possible using an
TABLE statement to set a foreign key on a partitioned
table; it was also possible to partition a table with a single
It was possible to execute a
CREATE TEMPORARY TABLE tmp
LIKE pt statement, where
pt is a
partitioned table, even though partitioned temporary tables are
not permitted. This caused the server to crash. Now a check is
performed to prevent such statements from being executed.
When attempting to perform DDL on a partitioned table and the
.par file could not be found,
the server returned the inaccurate error message Out
of memory; restart server and try again (needed 2
bytes). Now in such cases, the server returns the
error Failed to initialize partitions from .par
GROUP BY queries performed poorly for some
partitioned tables. This was due to the block size not being set
for partitioned tables, thus the keys per block was not correct,
which could cause such queries to be optimized incorrectly.
References: See also Bug #37252.
When using unique keys on
NULL columns in
row-based replication, the slave sometimes chose the wrong row
when performing an update. This happened because a table having
a unique key on such a column could have multiple rows
NULL for the column used by the
unique key, and the slave merely picked the first row containing
NULL in that column.
TEMPORARY TABLE ... SELECT statement was executed
within a transaction that updated only transactional engines and
was later rolled back (for example, due to a deadlock) the
changes—including the creation of the temporary
table—were not written to the binary log, which caused
subsequent updates to this table to fail on the slave.
When using the statement-based logging format, statements that
CONNECTION_ID() were always
kept in the transaction cache; consequently, nontransactional
changes that should have been flushed before the transaction
were kept in the transaction cache.
References: This bug was introduced by Bug #51894.
In some cases, attempting to update a column with a value of an
incompatible type resulted in a mismatch between master and
slave because the column value was set to its implicit default
value on the master (as expected), but the same column on the
slave was set to
Replication: ACK packets in semisynchronous replication were not checked for length and malformed packets could cause a server crash. (Bug #52748)
When temporary tables were in use, switching the binary logging
ROW did not take effect until all temporary
tables were dropped. (The existence of temporary tables should
prevent switching the format only from
STATEMENT from taking effect, not the
A buffer overrun in the handling of
DATE column values could cause
mysqlbinlog to fail when reading logs
containing certain combinations of DML statements on a table
DATE column followed by
dropping the table.
The failure of a
was logged with the wrong error code, causing replication slaves
to stop even when the failure was expected on the master.
Issuing any DML on a temporary table
TEMPORARY TABLE temp, both within the same
transaction, caused replication to fail.
The fix introduces a change to statement-based binary logging with respect to temporary tables. Within a transaction, changes to temporary tables are saved to the transaction cache and written to the binary log when the transaction commits. Otherwise, out-of-order logging of events could occur. This means that temporary tables are treated similar to transactional tables for purposes of caching and logging. This affects assessment of statements as safe or unsafe and the associated error message was changed from:
Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statements that read from both transactional and non-transactional tables and write to any of them are unsafe.
Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statements that read from both transactional (or a temporary table of any engine type) and non-transactional tables and write to any of them are unsafe.
References: See also Bug #51291, Bug #53075, Bug #53259, Bug #53452, Bug #54872. This bug was introduced by Bug #46364.
The internal flag indicating whether a user value was signed or
unsigned_flag) could sometimes
change between the time that the user value was recorded for
logging purposes and the time that the value was actually
written to the binary log, which could lead to inconsistency.
unsigned_flag is copied when the user
variable value is copied, and the copy of
unsigned_flag is then used for logging.
(Bug #51426, Bug #11759138)
References: See also Bug #49562, Bug #11757508.
causes nontransactional changes to be written to the binary log
upon committing the statement. However, even when not enabled,
the addition of this variable introduced a number of undesired
changes in behavior:
MIXED logging mode: Nontransactional
changes executed within a transaction prior to any
transactional changes were written to the statement cache,
but those following any transactional changes were written
to the transactional cache instead, causing these (later)
nontransactional changes to be lost.
MIXED logging mode: When rolling back a
transaction, any nontransactional changes that might be in
the transaction cache were disregarded and truncated along
with the transactional changes.
STATEMENT logging mode: A
statement that combined transactional and nontransactional
changes prior to any other transactional changes within the
transaction, but failed, was kept in the transactional cache
until the transaction ended, rather than being written to
the binary log at the instant of failure (and not deferred
to the end of the transaction).
These problems have been handled as follows:
When using statement-based logging with
ON, any statement combining
transactional and nontransactional changes within the same
transaction is now stored in the transaction cache, whether
or not it succeeds, and regardless of its order of execution
among any transactional statements within that transaction.
This means that such a statement is now written to the
binary log only on transaction commit or rollback.
References: This bug was introduced by Bug #46364.
Replication: When using temporary tables, the binary log needs to insert a pseudo-thread ID for threads that are using temporary tables, each time a switch happens between two threads, both of which are using temporary tables. However, if a thread issued a failing statement before exit, its ID was not recorded in the binary log, and this in turn caused the ID for the next thread that tried to do something with a temporary table not to be logged as well. Subsequent replays of the binary log failed with the error Table ... doesn't exist. (Bug #51226)
References: This bug is a regression of Bug #35583.
If the master was using
duplicate key errors were not sent to the slave, which received
0 rather than the expected error code. This
caused replication to fail even when such an error was expected.
DDL statements that lock tables (such as
CREATE INDEX, and
CREATE TRIGGER) caused spurious
errors, even though they did not insert rows into any tables.
binlog_format=ROW and a
statement modifies a table restricted to statement-based
binlog_format=STATEMENT and a
statement modifies a table restricted to row-based logging.
References: This bug was introduced by Bug #39934, Bug #11749859.
CREATE EVENT statement was
followed by an additional statement and the statements were
executed together as a single statement, the
CREATE EVENT statement was padded
with “garbage” characters when written to the
binary log. This led to a syntax error when the event was read
from the log.
When using a nontransactional table on the master with
autocommit disabled, no
was recorded in the binary log following a statement affecting
this table. If the slave's copy of the table used a
transactional storage engine, the result on the slave was as
though a transaction had been started, but never completed.
References: See also Bug #29288.
make_binary_distribution target to
make could fail on some platforms because the
lines generated were too long for the shell.
Inconsistent checking of the relationship between
SHOW statements and
INFORMATION_SCHEMA queries caused such
queries to fail sometimes.
Builds of the embedded mysqld failed due to a
missing element of the
(Bug #53908, Bug #53912)
The definition of the
MY_INIT macro in
my_sys.h included an extraneous semicolon,
which could cause compilation failure.
MySQL incorrectly processed
special` UPGRADE DATA
.., or a sequence starting with
../. It used the
server data directory (which contains other regular databases)
as the database directory.
(Bug #53804, CVE-2010-2008)
OPTIMIZE TABLE could be run on a
table in use by a transaction in a different session, causing
repeatable read to break.
statements that used quick select and index scan simultaneously
caused a server crash or assertion failure.
Certain path names passed to
LOAD_FILE() could cause a server
variable was changed after a stored procedure or prepared
statement had been cached, the change had no effect on
subsequent executions of the procedure or statement.
Incorrect results could be returned for
with an impossible
Lock_time value in the slow query log was
negative for stored routines.
DEFAULT produced an incorrect
On some systems, such as Mac OS X, the
sockaddr_in6 structures contain a
non-standard field (
sin6_len) that must be set but was not. This
resulted in host name lookup failure.
In the debug version of the server, the
FreeState() function could in some
circumstances be called twice, leading to an assertion failure.
statements could cause a server crash.
With a non-
latin1 ASCII-based current
character set, the server inappropriately converted
DATETIME values to strings. This
resulted in the optimizer not using indexes on such columns.
Semi-consistent read was implemented for
InnoDB to address Bug #3300.
Semi-consistent reads do not block when a nonmatching record is
already locked by some other transaction. If the record is not
locked, a lock is acquired, but is released if the record does
not match the
WHERE condition. However,
semi-consistent read was attempted even for
UPDATE statements having a
WHERE condition of the form
pk_col1=constant1, ..., pk_colN=constantN.
Some code failed that was designed with the assumption that
semi-consistent read would be only attempted on table scans.
to an empty string failed to clear the current debug settings.
SHOW CREATE TABLE was blocked if
the table was write locked by another session.
metadata values were incorrect for columns with the
TEXT family of data types that
used multibyte character sets. This bug was introduced in MySQL
mysql_upgrade attempted to work with stored routines before they were available. (Bug #52444)
function did not protect access to the
MyISAM open tables list, with the
result that server crashes could occur during table drop or
Spurious duplicate-key errors occurred for multiple-column
During MySQL server installation using the MSI package on
would be included in the default configuration template file.
This caused the MySQL server to fail to start properly.
Two sessions trying to set the global
event_scheduler system variable
OFF resulted in one of them hanging
waiting for the event scheduler to stop.
There was a race condition between flags used for signaling that a query was killed, which led to error-reporting and lock-acquisition problems. (Bug #52356)
For a concurrent load of 16 or more connections containing many
WRITE statements for the same table, server throughput
was significantly lower for MySQL 5.5.3 and 5.5.4 than for
earlier versions (10%–40% lower depending on concurrency).
Operations on geometry data types failed on some systems for builds compiled with Sun Studio. (Bug #52208)
The optimizer could attempt to evaluate the
WHERE clause before any rows had been read,
resulting in a server crash.
Cast operations on
DECIMAL values could cause server
crashes or Valgrind warnings.
An assertion was raised as a result of a
string being passed to the
A memory leak occurred due to missing deallocation of the
comparators array (a member of the
For debug builds, creating a view containing a subquery that might require collation adjustment caused an assertion to be raised. For example, this could occur if some items had different collations but the result collation could be adjusted to the one of them. (Bug #52120)
Aggregate functions could incorrectly return
NULL in outer join queries.
For outer joins, the optimizer could fail to properly calculate table dependencies. (Bug #52005)
COUNT(DISTINCT) query on a view
could cause a server crash.
cause a crash for some pathnames.
Stored routine DDL statements were written to the binary log using statement-based format regardless of the current logging format. (Bug #51839)
A problem with equality propagation optimization for prepared statements and stored procedures caused a server crash upon re-execution of the prepared statement or stored procedure. (Bug #51650)
References: See also Bug #8115, Bug #8849.
Locking involving the
LOCK_status mutexes could deadlock.
INFILE statement could sometimes lead to a server
The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug #51494)
The server could crash populating the
table due to lack of mutex protection.
HANDLER statements with
tables that had spatial indexes caused a server crash.
With an XA transaction active,
SET autocommit =
1 could cause side effects such as memory corruption
or a server crash.
CHECKSUM TABLE could compute the
BIT columns incorrectly.
ALTER TABLE on
InnoDB tables (including
partitioned tables) acquired exclusive locks on rows of the
table being altered. If there was a concurrent transaction that
did locking reads from this table, this sometimes led to a
deadlock that was not detected by the metadata lock subsystem or
by InnoDB (and was reported only after exceeding
HAVING clause on a joined table in some
cases failed to eliminate rows which should have been excluded
from the result set.
Two sessions trying to set the global
event_scheduler system variable
to different values could deadlock.
InnoDB fast index creation could
incorrectly use a table copy in some cases.
The Loose Index Scan optimization method assumed that it could depend on the partitioning engine to maintain interval endpoint information, as if it were a storage engine. (Bug #50939)
The type inference used for view columns caused some columns in
views to be handled as the wrong type, as compared to the same
columns in base tables.
columns in base tables were treated as
TIME columns in views, and base
TIME columns as view
A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug #50755)
Previously, the server held a global mutex while performing file
operations such as deleting an
.frm or data
file, or reading index statistics from a data file. Now the
mutex is not held for these operations. Instead, the server uses
(Bug #50589, Bug #51557, Bug #49463)
User-defined variables of type
NULL were handled improperly when
assigned to a column of another type.
--secure-file-priv to the
empty string left the value unaffected.
Calculation of intervals for Event Scheduler events was not portable. (Bug #50087)
0000 could be
treated as equal.
Performing a single in-place
ADD INDEX and
DROP INDEX options that used the same index
name could result in a corrupt table definition file. Now such
ALTER TABLE statements are no
longer performed in place.
mysql_upgrade did not detect when
CSV log tables incorrectly
contained columns that could be
these columns are altered to be
support-files/mysql.spec.sh had unnecessary
In MySQL 5.1,
was changed to use less locking due to the availability of
row-based binary logging (see the Note under
READ COMMITTED at
SET TRANSACTION Syntax). However,
READ UNCOMMITTED did not have
the same change, so it was using more locks than the higher
isolation level, which is unexpected. This was changed so that
READ UNCOMMITTED now also
uses the lesser amount of locking and has the same restrictions
for binary logging.
On Intel x86 machines, the optimizer could choose different execution plans for a query depending on the compiler version and optimization flags used to build the server binary. (Bug #48537)
A trigger could change the behavior of assigning
NULL to a
NOT NULL column.
The server crashed when it could not determine the best
execution plan for queries involving outer joins with
ON clauses such as the ones
RAND() function, a
user-defined function, or a
EXPLAIN could cause a server
crash for some queries with subqueries.
MERGE engine failed to open a
child table from a different database if the child table or
database name contained characters that were subject to table
name to file name encoding.
MERGE engine did not
properly open a child table from the same database if the child
table name contained characters such as
On Windows, the server failed to find a description for Event ID 100. (Bug #48042)
A query that read from a derived table (of the form
SELECT ... FROM (SELECT ...)) produced
incorrect results when the following conditions were present:
The table subquery contained a derived query
(SELECT ...) AS
The derived query could potentially produce zero rows or a
NULL (that is, no rows matched, or
the query used an aggregate function such as
SUM() running over zero
The table subquery joined at least two tables.
The join condition involved an index.
The optimization to read
MAX() values from an index did
not properly handle comparisons with
values. This could produce incorrect results for
WHERE clause tested a
NULL column for
Killing a query during the optimization phase of a subquery could cause a server crash. (Bug #47761)
MyISAM could write uninitialized
data to new index pages. Now zeros are written to unused bytes
in the pages.
For updates to
TIMESTAMP columns could be
updated even when no values actually changed.
mysqld_safe did not always pass
to mysqld. mysqld_safe did
not treat dashes and underscores as equivalent in option names.
When the transaction isolation level was
REPEATABLE READ and binary
logging used statement or mixed format,
SELECT statements with subqueries
unnecessarily acquired shared locks on rows in these tables.
In debug builds, if the listed columns in the view definition of
the table used in an
SELECT statement mismatched, an assertion was raised
in the query cache invalidation code following the failing
gcc 4.4.0 could fail to compile
ALTER TABLE ... ADD
COLUMN for a table with multiple foreign keys caused a
Manual pages for a few little-used programs were missing from RPM packages. (Bug #44370)
Using an initial command with
...) that generated multiple result sets (such as a
stored procedure or a multi-statement command) left the
The server could crash with an out of memory error when trying
to parse a query that was too long to fit in memory. Now the
parser rejects such queries with an
InnoDB could fail to create a unique index on
For a query that selected from a view and used an alias for the
view, the metadata used the alias name rather than the view name
mysql_upgrade did not create temporary files properly. (Bug #41057)
If the arguments to a
call included a local routine variable, selecting the return
value into a user variable could produce an incorrect result.
Column names displayed from the
PARTITION_EXPRESSION column of the
did not include escape characters as necessary.
TRANSACTION ISOLATION LEVEL was used to set the
isolation level for the next transaction, the level could
persist for subsequent transactions.
UNINSTALL PLUGIN to
remove a loaded plugin, open tables and connections caused
mysqld to hang until the open connections had
Valgrind warnings in the
compare_record() function were corrected.
The optimizer sometimes used
ORDER BY when it should have used an index.
Setting the session value of the
debug system variable also set
the global value.
MERGE table with an
empty underlying table list incorrectly resulted in a
“wrong index” error message rather than “end
The test for
readline during configuration
failed when trying to build MySQL in a directory other than the
source tree root.
mysqld could fail during execution when using SSL. (Bug #34236)
A query on a
FEDERATED table in which the
data was ordered by a
TEXT column returned
incorrect results. For example, a query such as the following
produced incorrect results if column
SELECT * FROM table1 ORDER BY column1;
MySQL Makefiles relied on GNU extensions. (Bug #30708)
The parser allocated too much memory for a query string containing multiple statements. (Bug #27863)
The behavior of the RPM installation for both new installations and upgrade installations has changed.
During a new installation, the server boot scripts are installed, but the MySQL server is not started at the end of the installation, since the status of the system during an unattended installation is not known.
During an upgrade installation using the RPM packages, if the server is running when the upgrade occurs, the server is stopped, the upgrade occurs, and server is restarted. If the server is not already running when the RPM upgrade occurs, the server is not started at the end of the installation.
The boot scripts for MySQL are installed in the appropriate
/etc, so the MySQL server
will be restarted automatically at the next machine reboot.
ROW_COUNT() returned a meaningful value only
for some DML statements. Now it returns a value as follows:
DML statements other than
SELECT: The number of
affected rows. This applies to statements such as
DELETE (as before), but now
also to statements such as
SELECT: -1 if the statement
returns a result set, or the number of rows
“affected” if it does not. For example, for
SELECT * FROM t1,
ROW_COUNT() returns -1. For
SELECT * FROM t1 INTO OUTFILE
ROW_COUNT() returns the
number of rows written to the file.
SIGNAL statements: 0.