MySQL now supports pluggable authentication, such that the server uses plugins to authenticate incoming client connections. Client programs load an authentication plugin that interacts properly with the corresponding server plugin.

Pluggable authentication enables two important capabilities, external authentication and proxy users:

Pluggable authentication entails these changes:

Proxy user capability entails these changes:

Due to these changes, the server requires that a new grant table, proxies_priv, be present in the mysql database. If you are upgrading to MySQL 5.5.7 from a previous MySQL release rather than performing a new installation, the server will find that this table is missing and exit during startup with the following message:

Table 'mysql.proxies_priv' doesn't exist

To create the proxies_priv table, start the server with the --skip-grant-tables option to cause it to skip the normal grant table checks, then run mysql_upgrade. For example:

shell> mysqld --skip-grant-tables &
shell> mysql_upgrade

Then stop the server and restart it normally.

You can specify other options on the mysqld command line if necessary. Alternatively, if your installation is configured so that the server normally reads options from an option file, use the --defaults-file option to specify the file (enter each command on a single line):

shell> mysqld --defaults-file=/usr/local/mysql/etc/my.cnf
         --skip-grant-tables &
shell> mysql_upgrade

With the --skip-grant-tables option, the server does no password or privilege checking, so any client can connect and effectively have all privileges. For additional security, use the --skip-networking option as well to prevent remote clients from connecting.

For additional information, consult these references:

MySQL releases now are built using CMake rather than the GNU autotools. Accordingly, the instructions for installing MySQL from source have been updated to discuss how to build MySQL using CMake. See Installing MySQL from Source. If you are familiar with autotools but not CMake, you might find these transition instructions helpful: Autotools to CMake Transition Guide

The build process is now similar enough on all platforms, including Windows, that there are no longer sections dedicated to notes for specific platforms.

The default installation layout when compiling from source now matches that used for binary distributions. You will notice these differences for installations from source distributions:

The make_binary_distribution and make_win_bin_dist scripts are now obsolete. To create a binary distribution, use make package.

Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), it renamed the current log file with the suffix -old, then created a new empty log file. This had the problem that a second log-flushing operation thus caused the original error log file to be lost unless you saved it under a different name. For example, you could use the following commands to save the file:

shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

To avoid the preceding file-loss problem, renaming no longer occurs. The server merely closes and reopens the log file. To rename the file, you can do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands:

shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

(Bug #29751)

References: See also Bug #56821.

A new status variable, Handler_read_last, displays the number of requests to read the last key in an index. With ORDER BY, the server issues a first-key request followed by several next-key requests, whereas with ORDER BY DESC, the server issues a last-key request followed by several previous-key requests. (Bug #52312)

The unused and undocumented thread_pool_size system variable was removed. (Bug #57338)

Added a new SHOW PROCESSLIST state, Waiting for query cache lock. This indicates that a session is waiting to take the query cache lock while it performs some query cache operation. (Bug #56822)

The pstack library was nonfunctional and has been removed, along with the --with-pstack option for configure and the --enable-pstack option for mysqld. (Bug #57210)

Previously, the server supported values of OFF, ON, and FORCE for the --plugin_name=value option format for controlling plugin loading using an option named after the plugin. Such options now support a FORCE_PLUS_PERMANENT value. This value is like FORCE, but in addition prevents the plugin from being unloaded at runtime. If a user attempts to do so with UNINSTALL PLUGIN, an error occurs. See Installing and Uninstalling Plugins.

In addition, the INFORMATION_SCHEMA.PLUGINS table now has a LOAD_OPTION column that indicates the plugin loading value (OFF, ON, FORCE, or FORCE_PLUS_PERMANENT). See The INFORMATION_SCHEMA PLUGINS Table.

Security Fix; Incompatible Change; InnoDB: Issuing TRUNCATE TABLE and examining the same table's information in the INFORMATION_SCHEMA database at the same time could cause a crash in the debug version of the server.

As a result of this change, InnoDB always uses the fast truncation technique, equivalent to DROP TABLE and CREATE TABLE. It no longer performs a row-by-row delete for tables with parent-child foreign key relationships. TRUNCATE TABLE returns an error for such tables. Modify your SQL to issue DELETE FROM table_name for such tables instead. (Bug #54678)

Security Fix: The PolyFromWKB() function could crash the server when improper WKB data was passed to the function. (Bug #51875, Bug #11759554, CVE-2010-3840)

Security Fix: In prepared-statement mode, EXPLAIN for a SELECT from a derived table caused a server crash. (Bug #54488)

Security Fix: The CONVERT_TZ() function crashed the server when the timezone argument was an empty SET column value. (Bug #55424)

Security Fix: EXPLAIN EXTENDED caused a server crash with some prepared statements. (Bug #54494)

Security Fix: The server crashed for assignment of values of types other than Geometry to items of type GeometryCollection (MultiPoint, MultiCurve, MultiSurface). Now the server checks the value type and fails with bad geometry value if it detects incorrect parameters. (Bug #55531)

Performance; InnoDB: The master InnoDB background thread could sometimes cause transient performance drops due to excessive flushing of modified pages. (Bug #56933)

Incompatible Change; Replication: The behavior of INSERT DELAYED statements when using statement-based replication has changed as follows:

Previously, when using binlog_format=STATEMENT, a warning was issued in the client when executing INSERT DELAYED; now, no warning is issued in such cases.

Previously, when using binlog_format=STATEMENT, INSERT DELAYED was logged as INSERT DELAYED; now, it is logged as an INSERT, without the DELAYED option.

However, when binlog_format=STATEMENT, INSERT DELAYED continues to be executed as INSERT (without the DELAYED option). The behavior of INSERT DELAYED remains unchanged when using binlog_format=ROW: INSERT DELAYED generates no warnings, is executed as INSERT DELAYED, and is logged using the row-based format.

This change also affects binlog_format=MIXED, because INSERT DELAYED is no longer considered unsafe. Now, when the logging format is MIXED, no switch to row-based logging occurs. This means that the statement is logged as a simple INSERT (that is, without the DELAYED option), using the statement-based logging format. (Bug #54579, Bug #11762035)

References: See also Bug #56678, Bug #11763907, Bug #57666. This bug was introduced by Bug #39934, Bug #11749859.

Incompatible Change: HANDLER ... READ statements that invoke stored functions can cause replication errors. Such statements are now disallowed and result in an ER_NOT_SUPPORTED_YET error. (Bug #54920)

Important Change; InnoDB: The server could crash with an assertion, possibly leading to data corruption, while updating the primary key of an InnoDB table containing BLOB or other columns requiring off-page storage. This fix applies to the InnoDB Plugin in MySQL 5.1, and to InnoDB 1.1 in MySQL 5.5. (Bug #55543)

InnoDB; Replication: If the master had innodb_file_per_table=OFF, innodb_file_format=Antelope (and innodb_strict_mode=OFF), or both, certain CREATE TABLE options, such as KEY_BLOCK_SIZE, were ignored. This could permit the master to avoid raising ER_TOO_BIG_ROWSIZE errors.

However, the ignored CREATE TABLE options were still written into the binary log, so that, if the slave had innodb_file_per_table=ON and innodb_file_format=Barracuda, it could encounter an ER_TOO_BIG_ROWSIZE error while executing the record from the log, causing the slave SQL thread to abort and replication to fail.

In the case where the master was running MySQL 5.1 and the slave was MySQL 5.5 (or later), the failure occurred when both master and slave were running with default values for innodb_file_per_table and innodb_file_format. This could cause problems during upgrades.

To address this issue, the default values for innodb_file_per_table and innodb_file_format are reverted to the MySQL 5.1 default values—that is, OFF and Antelope, respectively. (Bug #56318, Bug #11763590)

InnoDB: If the server crashed during a RENAME TABLE operation on an InnoDB table, subsequent crash recovery could fail. This problem could also affect an ALTER TABLE statement that caused a rename operation internally. (Bug #55027)

InnoDB: The output from the SHOW ENGINE INNODB STATUS command can now be up to 1MB. Formerly, it was truncated at 64KB. Monitoring applications that parse that output can check whether it exceeds this new, larger limit by testing the Innodb_truncated_status_writes status variable. (Bug #56922)

InnoDB: Changed the locking mechanism for the InnoDB data dictionary during ROLLBACK operations, to improve concurrency for REPLACE statements. (Bug #54538)

InnoDB: Improved the performance of UPDATE operations on InnoDB tables, when only non-indexed columns are changed. (Bug #56340)

InnoDB: The server could crash with a high volume of concurrent LOCK TABLES and UNLOCK TABLES statements. (Bug #57345)

InnoDB: The server could crash on shutdown, if started with --innodb-use-system-malloc=0. (Bug #55627)

InnoDB: A heavy workload with a large number of threads could cause a crash in the debug version of the server. (Bug #55699)

InnoDB: When MySQL was restarted after a crash with the option innodb_force_recovery=6, certain queries against InnoDB tables could fail, depending on WHERE or ORDER BY clauses.

Usually in such a disaster recovery situation, you dump the entire table using a query without these clauses. During advanced troubleshooting, you might use queries with these clauses to diagnose the position of the corrupted data, or to recover data following the corrupted part. (Bug #55832)

InnoDB: For debug builds, a SELECT ... FOR UPDATE statement affecting a range of rows in an InnoDB table could cause a server crash. (Bug #56716)

InnoDB: If the server crashed during an ALTER TABLE operation on an InnoDB table, examining the table through SHOW CREATE TABLE or querying the INFORMATION_SCHEMA tables could cause the server to stop with an assertion error. (Bug #56982)

InnoDB: InnoDB incorrectly reported an error when a cascading foreign key constraint deleted more than 250 rows. (Bug #57255)

InnoDB: InnoDB startup messages now include the start and end times for buffer pool initialization, and the total buffer pool size. (Bug #48026)

InnoDB: With multiple buffer pools enabled, InnoDB could flush more data from the buffer pool than necessary, causing extra I/O overhead. (Bug #54346)

InnoDB: The CHECK TABLE command could cause a time-consuming verification of the InnoDB adaptive hash index memory structure. Now this extra checking is only performed in binaries built for debugging. (Bug #55716)

InnoDB: InnoDB transactions could be incorrectly committed during recovery, rather than rolled back, if the server crashed and was restarted after performing ALTER TABLE ... ADD PRIMARY KEY on an InnoDB table, or some other operation that involves copying the entire table. (Bug #53756)

InnoDB: Setting the PACK_KEYS=0 table option for an InnoDB table prevented new indexes from being added to the table. (Bug #54606)

InnoDB: The server could crash when opening an InnoDB table linked through foreign keys to a long chain of child tables. (Bug #54582)

Partitioning: An ALTER TABLE statement acting on table partitions that failed while the affected table was locked could cause the server to crash. (Bug #56172)

Partitioning: Multiple-table UPDATE statements involving a partitioned MyISAM table could cause this table to become corrupted. Not all tables affected by the UPDATE needed to be partitioned for this issue to be observed. (Bug #55458)

Partitioning: EXPLAIN PARTITIONS returned bad estimates for range queries on partitioned MyISAM tables. In addition, values in the rows column of EXPLAIN PARTITIONS output did not take partition pruning into account. (Bug #53806, Bug #46754)

Replication: SET PASSWORD caused failure of row-based replication between a MySQL 5.1 master and a MySQL 5.5 slave.

This fix makes it possible to replicate SET PASSWORD correctly, using row-based replication between a master running MySQL 5.1.53 or a later MySQL 5.1 release to a slave running MySQL 5.5.7 or a later MySQL 5.5 release. (Bug #57098)

References: See also Bug #55452, Bug #57357.

Replication: When a slave tried to execute a transaction larger than the slave's value for max_binlog_cache_size, it crashed. This was caused by an assertion that the server should roll back only the statement but not the entire transaction when the error ER_TRANS_CACHE_FULL occurred. However, the slave SQL thread always rolled back the entire transaction whenever any error occurred, regardless of the type of error. (Bug #55375)

Replication: The error message for ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded in English in sql_yacc.yy, so that it could not be translated in errmsg.txt for other languages.

Additionally, this same error message was used for three separate error conditions:

These issues have been addressed as follows:

(Bug #54144)

Replication: Backticks used to enclose identifiers for savepoints were not preserved in the binary log, which could lead to replication failure when the identifier, stripped of backticks, could be misinterpreted, causing a syntax or other error.

This could cause problems with MySQL application programs making use of generated savepoint IDs. If, for instance, java.sql.Connection.setSavepoint() is called without any parameters, Connector/J automatically generates a savepoint identifier consisting of a string of hexadecimal digits 0-F encased in backtick (`) characters. If such an ID took the form `NeN` (where N represents a string of the decimal digits 0-9, and e is a literal uppercase or lowercase “E” character). Removing the backticks when writing the identifier into the binary log left behind a substring which the slave MySQL server tried to interpret as a floating point number, rather than as an identifier. The resulting syntax error caused loss of replication. (Bug #55961)

References: See also Bug #55962.

Replication: Prepared multiple-row INSERT DELAYED statements were written to the binary log without DELAYED. (Bug #56678, Bug #11763907)

References: This bug is a regression of Bug #54579, Bug #11762035.

Multiple-statement execution could fail. (Bug #40877)

The server entered an infinite loop with high CPU utilization after an error occurred during flushing of the I/O cache. (Bug #55629)

Performance for certain read-only queries, in particular point_select, had deteriorated compared to previous versions. (Bug #56585)

Using REPAIR TABLE tbl_name USE_FRM on a MERGE table caused the server to crash. (Bug #46339)

In LOAD DATA INFILE, using a SET clause to set a column equal to itself caused a server crash. (Bug #51850)

For the Performance Schema, the default number of rwlock classes was increased to 30, and the default number of rwlock and mutex instances was increased to 1 million. These changes were made to account for the volume of data instrumented when the InnoDB storage engine is used (because of the InnoDB buffer pool). (Bug #55576)

Trailing space removal for utf32 strings was done with non-multi-byte-safe code, leading to incorrect result length and assertion failure. (Bug #42511)

The plugin_ftparser.h and plugin_audit.h include files are part of the public API/ABI, but were not tested by the ABI check. (Bug #52821)

MIN() or MAX() with a subquery argument could raise a debug assertion for debug builds or return incorrect data for nondebug builds. (Bug #54465)

The fix for Bug #30234 caused the server to reject the DELETE tbl_name.* ... Access compatibility syntax for multiple-table DELETE statements. (Bug #53034)

INFORMATION_SCHEMA plugins with no deinit() method resulted in a memory leak. (Bug #54253)

If a view was named as the destination table for CREATE TABLE ... SELECT, the server produced a warning whether or not IF NOT EXISTS was used. Now it produces a warning only when IF NOT EXISTS is used, and an error otherwise. (Bug #55777)

Setting SETUP_INSTRUMENTS.TIMER = 'NO' caused TIMER_WAIT values for aggregations to be NULL rather than 0. (Bug #53874)

Short (single-letter) command-line options did not work. (Bug #55873)

Queries involving predicates of the form const NOT BETWEEN not_indexed_column AND indexed_column could return incorrect data due to incorrect handling by the range optimizer. (Bug #54802)

A negative TIME argument to MIN() or MAX() could raise an assertion. (Bug #56120)

After the fix for Bug #39653, the shortest available secondary index was used for full table scans. The primary clustered key was used only if no secondary index could be used. However, when the chosen secondary index includes all columns of the table being scanned, it is better to use the primary index because the amount of data to scan is the same but the primary index is clustered. This is now taken into account. (Bug #55656)

If one session attempted to drop a database containing a table which another session had opened with HANDLER, any instance of ALTER DATABASE, CREATE DATABASE, or DROP DATABASE issued by the latter session produced a deadlock. (Bug #54360)

In debug builds, the server raised an assertion for DROP DATABASE in installations that had an outdated or corrupted mysql.proc table. For example, this affected mysql_upgrade when run as part of a MySQL 5.1 to 5.5 upgrade. (Bug #56137)

The ordering for supplementary characters in the utf8mb4_bin, utf16_bin, and utf32_bin collations was incorrect. (Bug #55980)

It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug #56521)

An atomic “compare and swap” operation using x86 assembly code (32 bit) could access incorrect data, which would make it work incorrectly and lose the intended atomicity. This in turn caused the MySQL server to work on inconsistent data structures and return incorrect data. That code affected only 32-bit builds; the effect has been observed when icc was used to build binaries. With gcc, no incorrect results have been observed during tests, so this fix is a proactive one. Other compilers do not use this assembly code. (Bug #52419)

Row subqueries producing no rows were not handled as UNKNOWN values in row-comparison expressions. (Bug #54190)

In some cases, when the left part of a NOT IN subquery predicate was a row and contained NULL values, the query result was incorrect. (Bug #51070)

EXPLAIN produced an incorrect rows value for queries evaluated using an index scan and that included LIMIT, GROUP BY, and ORDER BY on a computed column. (Bug #50394)

A malformed packet sent by the server when the query cache was in use resulted in lost-connection errors. (Bug #42503)

For some queries, the optimizer produced incorrect results using the Index Merge access method with InnoDB tables. (Bug #50402)

With an UPDATE IGNORE statement including a subquery that was evaluated using a temporary table, an error transferring the data from the temporary was ignored, causing an assertion to be raised. (Bug #54543)

CREATE TABLE failed if a column referred to in an index definition and foreign key definition had different lettercases in the two definitions. (Bug #39932)

If a query specified a DATE or DATETIME value in a format different from 'YYYY-MM-DD HH:MM:SS', a greater-than-or-equal (>=) condition matched only greater-than values in an indexed TIMESTAMP column. (Bug #55779, Bug #50774, Bug #11758558)

If there was an active SELECT statement, an error arising during trigger execution could cause a server crash. (Bug #55421)

mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way. (Bug #47485)

A buffer overrun could occur when formatting DBL_MAX numbers. (Bug #57209)

The tcmalloc library was missing from binary MySQL packages for Linux. (Bug #56267)

If an application using the embedded server called mysql_library_init() a second time after calling mysql_library_init() and mysql_library_end() to start and stop the server, the application crashed when reading option files. (Bug #53251)

Assignment of InnoDB scalar subquery results to a variable resulted in unexpected S locks in READ COMMITTED transaction isolation level. (Bug #55382)

The max_length metadata value of MEDIUMBLOB types was reported as 1 byte greater than the correct value. (Bug #53296)

The server could crash during shutdown due to a race condition relating to Performance Schema cleanup. (Bug #55105, Bug #56324)

The server could crash inside memcpy() when reading certain Performance Schema tables. (Bug #56761, Bug #58003)

CHECKSUM TABLE for Performance Schema tables could cause a server crash due to uninitialized memory reads. (Bug #50557)

Memory leaks detected by Valgrind were corrected. (Bug #56709)

If the global and session debug system variables had the same value, the debug trace file could be closed twice, leading to freeing already freed memory and a server crash. (Bug #46165)

ALTER TABLE on a MERGE table could result in deadlock with other connections. (Bug #56292, Bug #57002)

An INSERT DELAYED statement for a MERGE table could cause deadlock if it occurred as part of a transaction or under LOCK TABLES, and there was a concurrent DDL or LOCK TABLES ... WRITE statement that tried to lock one of its underlying tables. (Bug #56251)

The server crashed if a table maintenance statement such as ANALYZE TABLE or REPAIR TABLE was executed on a MERGE table and opening and locking a child table failed. For example, this could happen if a child table did not exist or if a lock timeout happened while waiting for a conflicting metadata lock to disappear.

As a consequence of this bug fix, it is now possible to use CHECK TABLE for log tables without producing an error. (Bug #56422, Bug #56494)

In debug builds, FLUSH TABLE table_list WITH READ LOCK for a MERGE table led to an assertion failure if one of the table's children was not present in the list of tables to be flushed. (Bug #55273)

Deadlock could occur for heavily concurrent workloads consisting of a mix of DML, DDL, and FLUSH TABLES statements affecting the same set of tables. (Bug #56715, Bug #56404, Bug #56405)

A bad DBUG_PRINT statement in fill_schema_schemata() caused server crashes on Solaris. (Bug #54478)

Executing XA END after an XA transaction was already ended raised an assertion. (Bug #56448)

Comparison of one STR_TO_DATE() result with another could return incorrect results. (Bug #56271)

On Solaris with gcc 3.4.6, ha_example.so was built with DTrace support even if the server was not, causing plugin loading problems. (Bug #55966)

On Mac OS X, RENAME TABLE raised an assertion if the lower_case_table_names system variable was 2 and the old table name was specified in uppercase. (Bug #56595)

If ALTER EVENT failed to load an event after altering it, an assertion could be raised. This could occur, for example, if ALTER EVENT was killed with KILL QUERY. (Bug #44171)

When mysqld was started as a service on Windows and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), the server reassigned the file descriptors of the stdout and stderr streams to the file descriptor of the log file. On Windows, if stdout or stderr is not associated with an output stream, the file descriptor returns a negative value. Previously, this caused the file descriptor reassignment to fail and the server to abort. To avoid this problem on Windows, the server now first assigns the stdout and stderr streams to the log file stream by opening this file. This causes the stdout and stderr file descriptors to be nonzero and the server can successfully reassign them to the file descriptor of the log file. (Bug #56821)

References: This bug is a regression of Bug #29751.

mysqlcheck behaved differently depending on the order in which options were given on the command line. (Bug #35269)

CASE expressions with a mix of operands in different character sets sometimes returned incorrect results. (Bug #55744)

Constant SUBTIME() expressions could return incorrect results. (Bug #57039)

An assertion could be raised by DELETE on a view that referenced another view which in turn (directly or indirectly) referenced more than one table. (Bug #51099)

COALESCE() in MySQL 5.5 could return a result different from MySQL 5.1 for some arguments. (Bug #57095)

A SELECT statement could produce a number of rows different from a CREATE TABLE ... SELECT that was supposed to select the same rows. (Bug #56423)

References: This bug is a regression of Bug #38999.

When invoked to display a help message, mysqld also displayed spurious warning or error messages. (Bug #30025)