MySQL 5.5.33

# Functionality Added or Changed
* Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. For example: Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead. Option prefixes are no longer supported in MySQL 5.7; only full options are accepted.
* comp_err now checks to make sure that new errors are not being added to MySQL 5.1 or 5.5 because the set of errors for these series is frozen.
# Bugs Fixed
* Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known limitation that was in MySQL Server 5.6.12.
* Performance; InnoDB: When innodb_thread_concurrency is set to a non-zero value, there was a possibility that all innodb_concurrency_tickets would be released after each row was read, resulting in a concurrency check after each read. This could impact performance of all queries. One symptom could be higher system CPU usage. We strongly recommend that you upgrade to MySQL Server 5.6.13 if you use this setting. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x.
* MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were specified.
* InnoDB: When CHECK TABLE found a secondary index that contained the wrong number of entries, it would report an error but not mark the index as corrupt. CHECK TABLE now marks the index as corrupt when this error is encountered, but only the index is marked as corrupt, not the table. As a result, only the index becomes unusable until it is dropped and rebuilt. The table is unaffected.
* InnoDB: InnoDB would attempt to gather statistics on partially created indexes.
* InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB buffer pool could show an invalid page type for read-fixed blocks. This fix will show the unknown page type for blocks that are I/O-fixed for reading.
* InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer.
* InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string.
* InnoDB: During a transaction commit, prepare_commit_mutex is acquired to preserve the commit order. If the commit operation failed, the transaction would be rolled back but the mutex would not be released. Subsequent insert operations would not be able to acquire the same mutex. This fix frees prepare_commit_mutex during innobase_rollback.
* InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown) is set to 2 and the master thread enters the flush loop, the thread would not be able to exit under some circumstances. This could lead to a shutdown hang.
* InnoDB: After disabling foreign key checks with SET foreign_key_checks=0 and performing a DROP INDEX, the table was no longer accessible after restarting the server. This fix allows the table with missing foreign key indexes to be accessed when SET foreign_key_checks=0. When the table is accessible, the user must recreate the missing indexes to fulfill the foreign key constraints.
* InnoDB: Creating a table with a comment or default textual value containing an apostrophe that is escaped with a backslash would sometimes cause the InnoDB storage engine to omit foreign key definitions.
* InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE to change the character set of foreign key columns for a database with multiple tables with foreign key constraints would leave the database in an inconsistent state. Subsequent ALTER TABLE operations (using the COPY algorithm) with foreign_key_checks=1 would fail due to the detected inconsistency. Reversion of the partially executed ALTER TABLE operation would also fail, resulting in the loss of the table being altered. When running the same ALTER TABLE operation with a RENAME clause, the inconsistency would not be detected but if the ALTER TABLE operation failed for some other reason, reversion of the partially executed ALTER TABLE would fail with the same result.
* The bug fix temporarily disables foreign_key_checks while the previous table definition is restored.
* InnoDB: Successive deletes in descending key order would lead to under-filled InnoDB index pages. When an InnoDB index page is under-filled, it is merged with the left or right sibling node. The check performed to determine if a sibling node is available for merging was not functioning correctly.
* InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base.
* Partitioning: When upgrading to MySQL 5.5.31 or higher, a message is written into the output of mysql_upgrade when encountering a partitioned table for which the ALGORITHM option is required to maintain binary compatibility with the original; the message includes the ALTER TABLE statement required to make the change. For such a table having a sufficiently large number of partitions, the message was truncated with an error before the complete ALTER TABLE statement could be written.
* Partitioning: When a range specified in the WHERE condition of a query against a table partitioned by RANGE entirely within that of one of the partitions, the next partition was also checked for rows although it should have been pruned away.
* Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
* Replication: Some expressions employing variables were not handled correctly by LOAD DATA.
* Replication: Linker errors occurred if the header file log_event.h was included in an application containing multiple source files, because the file rpl_tblmap.cc was included in log_event.h. This fix moves the inclusion of rpl_tblmap.cc into the source files that use log_event.h.
* Installation of Solaris PKG packages could fail to execute mysql_install_db because it was invoked with the --random-passwords option (which does not exist until MySQL 5.6).
* Initialization of keycache_* variables (see Multiple Key Caches) during server startup could write to incorrect memory.
* Removing a server RPM package did not shut down the existing server if it was running.
* The code base was modified to account for new warning checks introduced by gcc 4.8.
* Upgrading from community SLES RPM packages to commercial packages for the same MySQL version failed with conflict errors.
* A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory.
* Misoptimization of left expressions in prepared statements could cause a server exit.
* Out-of-bounds reads could occur within filename_to_tablename().
* When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE that requested table_name and index_name values, query results would include index pages without table_name or index_name values.
* With the thread pool plugin in use, normal connection termination caused the Aborted_clients status variable to be incremented.
* MySQL Installer, if run in custom install or change mode, offered installation options that had no effect.
* Incorrect results could be returned from queries that used several aggr_func(DISTINCT) functions (where aggr_func() is an aggregate function such as COUNT()) when these referred to different columns of the same composite key.
* Assigning the result of a subquery to a user variable raised an assertion when the outer query included DISTINCT and GROUP BY.
* mysqldump assumed the existence of the general_log and slow_log tables in the mysql database. It failed if invoked to dump tables from an older server where these tables do not exist.
* Attempts to build from a source RPM package could fail because the build process attempted to refer to a pb2user that might not exist.
* A typo in cmake/dtrace.cmake prevented DTrace support from being enabled by -DENABLE_DTRACE-on.
* RPM source packages did not list libaio-devel as a dependency, causing builds to fail.
* Comparison of a DATETIME value and a string did not work correctly for the utf8_unicode_ci collation.