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” quality.

InnoDB is now the default storage engine, rather than MyISAM, in the regular and enterprise versions of MySQL. This change has the following consequences:

Follow these steps to ensure a smooth transition when upgrading:

Incompatible Change: All numeric operators and functions on integer, floating-point and DECIMAL values now throw an “out of range” error (ER_DATA_OUT_OF_RANGE) rather than returning an incorrect value or NULL, when the result is out of the supported range for the corresponding data type. See Out-of-Range and Overflow Handling. (Bug #8433)

InnoDB: The INFORMATION_SCHEMA.INNODB_TRX table now includes a number of fields that duplicate information from the SHOW ENGINE INNODB STATUS output. You no longer need to parse that output to get complete transaction information. (Bug #53336)

InnoDB: 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). (Bug #53122)

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 --skip-name-resolve server option. This provides a way to determine at runtime whether the server uses name resolution for client connections. (Bug #37168)

For events of MYSQL_AUDIT_GENERAL_CLASS, the 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:

The 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. (Bug #47059)

The Rows_examined value in slow query log rows now is nonzero for UPDATE and DELETE statements that modify rows. (Bug #49756)

Previously, the innodb_file_format_check system variable served a dual purpose. Setting it at server startup would keep InnoDB from starting if any tables used a more recent file format than supported by the current level of InnoDB. If InnoDB 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 InnoDB, an error occurs and InnoDB does not start. If the tag is not higher, InnoDB sets the value of innodb_file_format_max to the file format tag.

For background information about InnoDB file-format management, see InnoDB File-Format Management. (Bug #49792, Bug #53654)

Added the SHA2() function, which calculates the SHA-2 family of hash functions (SHA-224, SHA-256, SHA-384, and SHA-512). (Contributed by Bill Karwin) (Bug #13174)

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.

Security Fix: Privilege checking for UNINSTALL 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: 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 COM_FIELD_LIST.

In MySQL 5.0 and above, this permitted an authenticated user with 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 user with DELETE or 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)

Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a 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)

Security Fix: LOAD DATA 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: The server could crash if there were alternate reads from two indexes on a table using the HANDLER interface. (Bug #54007, CVE-2010-3681)

Security Fix: A security bug was fixed. (Bug #52315)

Security Fix: A security bug was fixed. (Bug #53933)

Security Fix: A security bug was fixed. (Bug #53907)

Security Fix: A security bug was fixed. (Bug #48157)

Security Fix: A security bug was fixed. (Bug #52357)

Performance; InnoDB: 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. (Bug #49047)

Performance: 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. (Bug #39653)

References: See also Bug #55656.

Incompatible Change: 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 InnoDB 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). (Bug #42643)

Incompatible Change: After SET 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 SET TRANSACTION 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 SET TRANSACTION ISOLATION LEVEL statement, if there was any. (Bug #20837)

Important Change; Replication: It was possible to set sql_log_bin with session scope inside a transaction or subquery. (Bug #53437)

Important Change; Replication: When invoked, CHANGE MASTER TO and SET GLOBAL 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 CHANGE MASTER TO, this information includes the previous values of MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET GLOBAL sql_slave_skip_counter, this information includes the previous values of RELAY_LOG_FILE, RELAY_LOG_POS, and sql_slave_skip_counter. (Bug #43406, Bug #43407)

Important Change; Replication: When changing binlog_format or binlog_direct_non_transactional_updates, 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: When using fast ALTER TABLE, different internal ordering of indexes in the MySQL optimizer and the InnoDB storage engine could cause error messages about possibly mixed up .frm files and incorrect index use. (Bug #47622)

InnoDB; Replication: 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 MyISAM 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. (Bug #49019)

InnoDB; Replication: TRUNCATE TABLE performed on a temporary table using the InnoDB storage engine was logged even when using row-based mode. (Bug #51251)

InnoDB: The server could crash during shutdown, if started with the option --innodb_use_sys_malloc=0. (Bug #52546)

InnoDB: Some combinations of SELECT and SELECT FOR UPDATE statements could fail with errors about locks, or incorrectly release a row lock during a semi-consistent read operation. (Bug #53674)

InnoDB: The server could crash with a message InnoDB: Assertion failure in thread nnnn, typically during shutdown on a Windows system. (Bug #53947)

InnoDB: The values of innodb_buffer_pool_pages_total and innodb_buffer_pool_pages_misc in the information_schema.global_status table could be computed incorrectly. (Bug #52983)

InnoDB: Multi-statement execution could fail with an error about foreign key constraints. This problem could affect calls to mysql_query() and mysql_real_query(), and CALL statements that invoke stored procedures. (Bug #48024)

InnoDB: 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. (Bug #53248)

InnoDB: InnoDB checks to see whether a row could possibly exceed the maximum size if all columns are fully used. This produced 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. (Bug #50495)

InnoDB: Adding a unique key on multiple columns, where one of the columns is NULL, could mistakenly report duplicate key errors. (Bug #53290)

InnoDB: A mismatch between index information maintained within the .frm files and the corresponding information in the InnoDB system tablespace could produce this error: [ERROR] Index index of table has n columns unique inside InnoDB, but MySQL is asking statistics for m columns. Have you mixed up .frm files from different installations? (Bug #44571)

InnoDB: Connections waiting for an InnoDB row lock ignored 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. (Bug #51920)

InnoDB: An overly strict assertion could fail during the purge of delete-marked records in DYNAMIC or COMPRESSED InnoDB tables that contain column prefix indexes. (Bug #52746)

InnoDB: 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 DYNAMIC and COMPRESSED formats, InnoDB stores locally any non-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 REDUNDANT and COMPACT formats, because there InnoDB always stores locally columns having a length up to local_len = 788 bytes. (Bug #52745)

InnoDB: InnoDB page splitting could enter an infinite loop for compressed tables. (Bug #52964)

InnoDB: When reporting a foreign key constraint violation during INSERT, InnoDB could display uninitialized data for the DB_TRX_ID and DB_ROLL_PTR system columns. (Bug #53202)

Partitioning; Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging mode caused the master to hang or crash. (Bug #51851)

Partitioning; Replication: The NO_DIR_IN_CREATE server SQL mode was not enforced when defining subpartitions. In certain cases, this could lead to failures on replication slaves. (Bug #42954)

Partitioning: Rows inserted into a table created using a PARTITION BY LIST COLUMNS option referencing multiple columns could be inserted into the wrong partition. (Bug #52815)

Partitioning: When attempting to perform DDL on a partitioned table and the table's .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 file. (Bug #49161)

Partitioning: ALTER TABLE statements that cause table partitions to be renamed or dropped (such as ALTER TABLE ... ADD PARTITION, ALTER TABLE ... DROP PARTITION, and ALTER TABLE ... REORGANIZE PARTITION) — when run concurrently with queries against the INFORMATION_SCHEMA.PARTITIONS table — 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 ALTER TABLE statement on the partitions affected. In particular, this led to problems with InnoDB tables, because 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, INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER TABLE statements that cause partitions to be renamed or dropped. (Bug #50561)

References: See also Bug #47343, Bug #45808.

Partitioning: 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. (Bug #49477)

Partitioning: 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 range. (Bug #51830)

Partitioning: Attempting to partition a table using a DECIMAL column caused the server to crash; this was not supported and is now specifically not permitted. (Bug #51347)

Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM table having an AUTO_INCREMENT column. (Bug #50392)

Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible using an ALTER TABLE statement to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key. (Bug #50104)

Partitioning: 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. (Bug #48229)

References: See also Bug #37252.

Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug #46565)

Replication: 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 containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that column. (Bug #53893)

Replication: When a CREATE 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. (Bug #53421)

Replication: DDL statements that lock tables (such as ALTER TABLE, CREATE INDEX, and CREATE TRIGGER) caused spurious ER_BINLOG_ROW_MODE_AND_STMT_ENGINE or ER_BINLOG_STMT_MODE_AND_ROW_ENGINE errors, even though they did not insert rows into any tables.

(Bug #50479)

References: This bug was introduced by Bug #39934, Bug #11749859.

Replication: 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 NULL. (Bug #52868)

Replication: When using a nontransactional table on the master with autocommit disabled, no COMMIT 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. (Bug #49522)

References: See also Bug #29288.

Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even when the failure was expected on the master. (Bug #51987)

Replication: 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 having a DATE column followed by dropping the table. (Bug #52202)

Replication: When using the statement-based logging format, statements that used 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. (Bug #53075)

References: This bug was introduced by Bug #51894.

Replication: When temporary tables were in use, switching the binary logging format from STATEMENT to ROW did not take effect until all temporary tables were dropped. (The existence of temporary tables should prevent switching the format only from ROW to STATEMENT from taking effect, not the reverse.) (Bug #52616)

Replication: Issuing any DML on a temporary table temp followed by DROP 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.

To:

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.

(Bug #51894)

References: See also Bug #51291, Bug #53075, Bug #53259, Bug #53452, Bug #54872. This bug was introduced by Bug #46364.

Replication: Enabling binlog_direct_non_transactional_updates 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:

These problems have been handled as follows:

(Bug #51291)

References: This bug was introduced by Bug #46364.

Replication: When run with the --database option, mysqlbinlog printed ROLLBACK statements but did not print any corresponding SAVEPOINT statements. (Bug #50407)

Replication: When a 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. (Bug #50095)

Replication: The internal flag indicating whether a user value was signed or unsigned (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. Now 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.

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.

Replication: If the master was using sql_mode='TRADITIONAL', 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. (Bug #51055)

Replication: ACK packets in semisynchronous replication were not checked for length and malformed packets could cause a server crash. (Bug #52748)

For updates to InnoDB tables, TIMESTAMP columns could be updated even when no values actually changed. (Bug #47453)

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.

Accessing a MERGE table with an empty underlying table list incorrectly resulted in a “wrong index” error message rather than “end of file.” (Bug #35274)

Setting the session value of the debug system variable also set the global value. (Bug #38054)

ALTER TABLE ... ADD COLUMN for a table with multiple foreign keys caused a server crash. (Bug #45052)

Using REPLACE to update a previously inserted negative value in an AUTO_INCREMENT column of an InnoDB table caused the table auto-increment value to be updated to 2147483647. (Bug #47720)

During MySQL server installation using the MSI package on Windows, the default-character-set option would be included in the default configuration template file. This caused the MySQL server to fail to start properly. (Bug #52380)

The make_binary_distribution target to make could fail on some platforms because the lines generated were too long for the shell. (Bug #54590)

mysqld could fail during execution when using SSL. (Bug #34236)

Builds of the embedded mysqld failed due to a missing element of the struct NET. (Bug #53908, Bug #53912)

Executing a LOAD XML INFILE statement could sometimes lead to a server crash. (Bug #51571)

When using UNINSTALL PLUGIN to remove a loaded plugin, open tables and connections caused mysqld to hang until the open connections had been closed. (Bug #39053)

A query that read from a derived table (of the form SELECT ... FROM (SELECT ...)) produced incorrect results when the following conditions were present:

(Bug #47904)

A HAVING clause on a joined table in some cases failed to eliminate rows which should have been excluded from the result set. (Bug #51242)

Performing a single in-place ALTER TABLE containing 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. (Bug #49838)

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. DATE columns in base tables were treated as TIME columns in views, and base table TIME columns as view DATETIME columns. (Bug #50918)

The 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.

Further, the MERGE engine did not properly open a child table from the same database if the child table name contained characters such as '/', or '#'. (Bug #48265)

CHECKSUM TABLE could compute the checksum for BIT columns incorrectly. (Bug #51304)

mysql_upgrade did not detect when CSV log tables incorrectly contained columns that could be NULL. Now these columns are altered to be NOT NULL. (Bug #49823)

The query shown by EXPLAIN EXTENDED plus SHOW WARNINGS could produce results different from the original query. (Bug #47669)

Two sessions trying to set the global event_scheduler system variable to different values could deadlock. (Bug #51160)

For LDML-defined collations, some data structures were not initialized properly to enable UPPER() and LOWER() to work correctly. (Bug #51976)

Invalid memory reads occurred for HANDLER ... READ NEXT after a failed HANDLER ... READ FIRST. (Bug #51877)

The YEAR values 2000 and 0000 could be treated as equal. (Bug #49910)

The optimizer performed an incorrect join type when COALESCE() appeared within an IN() operation. (Bug #51598)

Following a bulk insert into a MyISAM table, if MyISAM failed to build indexes using repair by sort, data file corruption could occur. (Bug #51307)

With an XA transaction active, SET autocommit = 1 could cause side effects such as memory corruption or a server crash. (Bug #51342)

The optimization to read MIN() or MAX() values from an index did not properly handle comparisons with NULL values. This could produce incorrect results for MIN() or MAX()when the WHERE clause tested a NOT NULL column for NULL. (Bug #47762)

Killing a query during the optimization phase of a subquery could cause a server crash. (Bug #47761)

Setting myisam_repair_threads larger than 1 could result in the cardinality for all indexes of a MyISAM table being set to 1 after parallel index repair. (Bug #47444)

Use of HANDLER statements with tables that had spatial indexes caused a server crash. (Bug #51357)

The server crashed when it could not determine the best execution plan for queries involving outer joins with nondeterministic ON clauses such as the ones containing the RAND() function, a user-defined function, or a NOT DETERMINISTIC stored function. (Bug #48483)

mysql_upgrade did not create temporary files properly. (Bug #41057)

On Windows, LOAD_FILE() could cause a crash for some pathnames. (Bug #51893)

It was possible for DROP TABLE of one MyISAM table to remove the data and index files of a different MyISAM table. (Bug #40980)

If myisam_sort_buffer_size was set to a small value, table repair for MyISAM tables with FULLTEXT indexes could crash the server. (Bug #51866)

EXPLAIN EXTENDED crashed trying to resolve references to freed temporary table columns for GROUP_CONCAT() ORDER BY arguments. (Bug #52397)

In debug builds, if the listed columns in the view definition of the table used in an INSERT ... SELECT statement mismatched, an assertion was raised in the query cache invalidation code following the failing statement. (Bug #46615)

The optimizer could attempt to evaluate the WHERE clause before any rows had been read, resulting in a server crash. (Bug #52177)

If the arguments to a CONCAT() call included a local routine variable, selecting the return value into a user variable could produce an incorrect result. (Bug #40625)

The test for readline during configuration failed when trying to build MySQL in a directory other than the source tree root. (Bug #35250)

MyISAM could write uninitialized data to new index pages. Now zeros are written to unused bytes in the pages. (Bug #47598)

The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug #51494)

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 in the MYSQL_FIELD.table member. (Bug #41788)

The server could crash populating the INFORMATION_SCHEMA.PROCESSLIST table due to lack of mutex protection. (Bug #51377)

After TRUNCATE TABLE of a MyISAM table, subsequent queries could crash the server if myisam_use_mmap was enabled. (Bug #51868)

Setting @@GLOBAL.debug to an empty string failed to clear the current debug settings. (Bug #52629)

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)

User-defined variables of type REAL that contained NULL were handled improperly when assigned to a column of another type. (Bug #50511)

Stored routine DDL statements were written to the binary log using statement-based format regardless of the current logging format. (Bug #51839)

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. (Bug #52849)

SHOW CREATE TABLE was blocked if the table was write locked by another session. (Bug #52593)

mysql_upgrade attempted to work with stored routines before they were available. (Bug #52444)

A COUNT(DISTINCT) query on a view could cause a server crash. (Bug #51980)

Corrupt MyISAM tables were automatically repaired even when myisam_recover_options was set to OFF. (Bug #51327)

Two sessions trying to set the global event_scheduler system variable to OFF resulted in one of them hanging waiting for the event scheduler to stop. (Bug #52367)

An assertion was raised as a result of a NULL string being passed to the dtoa code. (Bug #52165)

OPTIMIZE TABLE for an InnoDB table could raise an assertion if another session issued a concurrent DROP TABLE. (Bug #47459)

Certain path names passed to LOAD_FILE() could cause a server crash. (Bug #53417)

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)

Locking involving the LOCK_plugin, LOCK_global_system_variables, and LOCK_status mutexes could deadlock. (Bug #51591)

InnoDB fast index creation could incorrectly use a table copy in some cases. (Bug #50946)

If the server is started with --skip-grant-tables, plugin loading and unloading should be prohibited, but the server failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN statements. (Bug #46261)

On Windows, the server failed to find a description for Event ID 100. (Bug #48042)

A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug #50755)

A memory leak occurred due to missing deallocation of the comparators array (a member of the Arg_comparator class). (Bug #52124)

EXPLAIN could cause a server crash for some queries with subqueries. (Bug #48419)

mysqld_safe set plugin_dir using a hardcoded default path name rather than a path depending on basedir. (Bug #52737)

In MySQL 5.1, READ COMMITTED 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. (Bug #48607)

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. (Bug #52663)

mysqld_safe did not always pass --open-files-limit through to mysqld. mysqld_safe did not treat dashes and underscores as equivalent in option names. (Bug #47095)

InnoDB could fail to create a unique index on NULL columns. (Bug #41904)

Using an initial command with mysql_options(..., MYSQL_INIT_COMMAND, ...) that generated multiple result sets (such as a stored procedure or a multi-statement command) left the connection unusable. (Bug #42373)

mysqldump and SELECT ... INTO OUTFILE truncated long BLOB and TEXT values to 766 bytes. (Bug #53088)

Setting --secure-file-priv to the empty string left the value unaffected. (Bug #50373)

UPDATE on an InnoDB table modifying the same index that was used to satisfy the WHERE condition could trigger a debug assertion under some circumstances. (Bug #53830)

In the debug version of the server, the FreeState() function could in some circumstances be called twice, leading to an assertion failure. (Bug #52884)

Valgrind warnings resulting from passing incomplete DATETIME values to the TIMESTAMP() function were corrected. (Bug #53942)

Calculation of intervals for Event Scheduler events was not portable. (Bug #50087)

A trigger could change the behavior of assigning NULL to a NOT NULL column. (Bug #48525)

Selecting from INFORMATION_SCHEMA.ROUTINES or INFORMATION_SCHEMA.PARAMETERS resulted in a memory leak. (Bug #48729)

Aggregate functions could incorrectly return NULL in outer join queries. (Bug #52051)

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)

Incorrect results could be returned for LEFT JOIN of InnoDB tables with an impossible WHERE condition. (Bug #53334)

When the transaction isolation level was REPEATABLE READ and binary logging used statement or mixed format, SELECT statements with subqueries referencing InnoDB tables unnecessarily acquired shared locks on rows in these tables. (Bug #46947)

For single-table DELETE statements that used quick select and index scan simultaneously caused a server crash or assertion failure. (Bug #53450)

MySQL incorrectly processed ALTER DATABASE `#mysql50#special` UPGRADE DATA DIRECTORY NAME where special was ., .., or a sequence starting with ./ or ../. It used the server data directory (which contains other regular databases) as the database directory. (Bug #53804, CVE-2010-2008)

InnoDB crashed when replacing duplicates in a table after a fast ALTER TABLE added a unique index. (Bug #53592)

For InnoDB tables, the error handler for a fast CREATE INDEX did not reset the error state of the transaction before attempting to undo a failed operation, resulting in a crash. (Bug #53591)

The definition of the MY_INIT macro in my_sys.h included an extraneous semicolon, which could cause compilation failure. (Bug #53906)

On some systems, such as Mac OS X, the sockaddr_in and sockaddr_in6 structures contain a non-standard field (sin_len / sin6_len) that must be set but was not. This resulted in host name lookup failure. (Bug #52923)

gcc 4.4.0 could fail to compile dtoa.c. (Bug #45882)

Spurious duplicate-key errors occurred for multiple-column indexes on BINARY columns. (Bug #52430)

Cast operations on NULL DECIMAL values could cause server crashes or Valgrind warnings. (Bug #52168)

ALTER TABLE for views is not legal but did not produce an error. (If you need to rename a view, use RENAME TABLE.) (Bug #53976)

Valgrind warnings in the InnoDB compare_record() function were corrected. (Bug #38999)

Operations on geometry data types failed on some systems for builds compiled with Sun Studio. (Bug #52208)

Column names displayed from the PARTITION_EXPRESSION column of the INFORMATION_SCHEMA.PARTITIONS table did not include escape characters as necessary. (Bug #39338)

Concurrent SHOW COLUMNS statements could cause a server crash. (Bug #52856)

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 metadata locks. (Bug #50589, Bug #51557, Bug #49463)

A crash occurred if a table that was locked with LOCK TABLES was listed twice in a DROP TABLE statement. (Bug #54282)

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 ER_OUT_OF_RESOURCES error. (Bug #42064)

OPTIMIZE TABLE could be run on a table in use by a transaction in a different session, causing repeatable read to break. (Bug #53798)

The Lock_time value in the slow query log was negative for stored routines. (Bug #53191)

For a concurrent load of 16 or more connections containing many LOCK TABLES 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). (Bug #52289)

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)

For outer joins, the optimizer could fail to properly calculate table dependencies. (Bug #52005)

Queries that used MIN() or MAX() on indexed columns could be optimized incorrectly. (Bug #53859)

The optimizer sometimes used filesort for ORDER BY when it should have used an index. (Bug #38745)

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 innodb_lock_wait_timeout). (Bug #51263)

The length and max_length metadata values were incorrect for columns with the TEXT family of data types that used multi-byte character sets. This bug was introduced in MySQL 5.5.3. (Bug #52520)

When SET TRANSACTION ISOLATION LEVEL was used to set the isolation level for the next transaction, the level could persist for subsequent transactions. (Bug #39170)

The AND CHAIN option for COMMIT and ROLLBACK failed to preserve the current transaction isolation level. Setting completion_type to 1 also failed to do so. (Bug #53343)

Setting the innodb_change_buffering system variable to DEFAULT produced an incorrect result. (Bug #53165)

Inconsistent checking of the relationship between SHOW statements and INFORMATION_SCHEMA queries caused such queries to fail sometimes. (Bug #54422)

For the COMMIT and ROLLBACK statements, the AND CHAIN and RELEASE modifiers should be mutually exclusive, but the parser permitted both to be specified. (Bug #46527)

If the completion_type session 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. (Bug #53346)

The check_table_is_closed() debugging function did not protect access to the MyISAM open tables list, with the result that server crashes could occur during table drop or rename operations. (Bug #52432)

Manual pages for a few little-used programs were missing from RPM packages. (Bug #44370)

support-files/mysql.spec.sh had unnecessary Perl dependencies. (Bug #49723)

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 directories in /etc, so the MySQL server will be restarted automatically at the next machine reboot. (Bug #27072)

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 column1 was a TEXT column:

SELECT * FROM table1 ORDER BY column1;

(Bug #32426)

The parser allocated too much memory for a query string containing multiple statements. (Bug #27863)

MySQL Makefiles relied on GNU extensions. (Bug #30708)

ROW_COUNT() returned a meaningful value only for some DML statements. Now it returns a value as follows:

(Bug #21818)