Documentation Home
MySQL 5.5 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 1.7Mb
PDF (A4) - 1.7Mb

MySQL 5.5 Release Notes  /  Changes in MySQL 5.5.16 (2011-09-15, General Availability)

Changes in MySQL 5.5.16 (2011-09-15, General Availability)

Pluggable Authentication

  • MySQL Enterprise Edition now includes two plugins that enable MySQL Server to use external authentication methods to authenticate MySQL users:

    • PAM (Pluggable Authentication Modules) enables a system to access various kinds of authentication methods through a standard interface. A PAM authentication plugin enables MySQL Server to use PAM to authenticate MySQL users.

      The PAM plugin uses the information passed to it by the MySQL server (such as user name, host name, password, and authentication string), plus whatever is available for PAM lookup (such as Unix passwords or an LDAP directory). The plugin checks the user credentials against PAM and returns success or failure.

      The PAM authentication plugin has been tested on Linux and OS X.


      The PAM plugin works with a client-side plugin that simply sends the password to the server in clear text so it can be passed to PAM. This may be a security problem in some configurations, but is necessary to use the server-side PAM library. To avoid problems if there is any possibility that the password would be intercepted, clients should connect to MySQL Server using SSL. See Client-Side Cleartext Pluggable Authentication.

    • MySQL Enterprise Edition distributions for Windows include an authentication plugin that enables MySQL Server to use native Windows services to authenticate client connections. Users who have logged in to Windows can connect from MySQL client programs to the server based on the information in their environment without specifying an additional password.

      The client and server exchange data packets in the authentication handshake. As a result of this exchange, the server creates a security context object that represents the identity of the client in the Windows OS. This identity includes the name of the client account. The Windows authentication plugin uses the identity of the client to check whether it is a given account or a member of a group. By default, negotiation uses Kerberos to authenticate, then NTLM if Kerberos is unavailable.

      The Windows authentication plugin is supported on any version of Windows supported by MySQL 5.5.

    These authentication plugins enable MySQL Server to accept connections from users defined outside the MySQL grant tables. They also support the MySQL proxy-user capability. Each plugin can return to MySQL a user name different from the login user, which means that the plugin can return the MySQL user that defines the privileges the externally authenticated user should have. For example, an external user named joe can connect and have the privileges of the MySQL user named developer.

    The server-side PAM and Windows authentication plugins are included only in commercial distributions. They are not included in MySQL community distributions. The client-side plugins with which they communicate are included in all distributions, including community distributions. This permits clients from any release to connect to a server that has the server-side plugin loaded.

    For more information about these plugins, see PAM Pluggable Authentication, and Windows Pluggable Authentication. For general information about pluggable authentication in MySQL, see Pluggable Authentication. For proxy user information, see Proxy Users.

Thread Pool Notes

  • The default thread-handling model in MySQL Server executes statements using one thread per client connection. As more clients connect to the server and execute statements, overall performance degrades. Commercial distributions of MySQL now include a thread pool plugin that provides an alternative thread-handling model designed to reduce overhead and improve performance. The plugin implements a thread pool that increases server performance by efficiently managing statement execution threads for large numbers of client connections.

    The thread pool addresses several problems of the one thread per connection model:

    • Too many thread stacks make CPU caches almost useless in highly parallel execution workloads. The thread pool promotes thread stack reuse to minimize the CPU cache footprint.

    • With too many threads executing in parallel, context switching overhead is high. This also presents a challenging task to the operating system scheduler. The thread pool controls the number of active threads to keep the parallelism within the MySQL server at a level that it can handle and that is appropriate for the server host on which MySQL is executing.

    • Too many transactions executing in parallel increases resource contention. In InnoDB, this increases the time spent holding central mutexes. The thread pool controls when transactions start to ensure that not too many execute in parallel.

    On Windows, the thread pool plugin requires Windows Vista or newer. On Linux, the plugin requires kernel 2.6.9 or newer.

    For more information, see MySQL Enterprise Thread Pool.

Functionality Added or Changed

  • Important Change; Replication: The RESET SLAVE statement has been extended with an ALL keyword. In addition to deleting the,, and all relay log files, RESET SLAVE ALL also clears all connection information otherwise held in memory following execution of RESET SLAVE. (Bug #11809016, Bug #11763210)

  • The thread pool plugin should be loaded at server startup, and not loaded or unloaded at runtime. An error now occurs for attempts to load or unload it with the INSTALL PLUGIN or UNINSTALL PLUGIN statement.

  • Some plugins operate in such a matter that they should be loaded at server startup, and not loaded or unloaded at runtime. The plugin API now supports marking plugins this way. The st_mysql_plugin structure now has a flags member, which can be set to the OR of the applicable flags. The PLUGIN_OPT_NO_INSTALL flag indicates that the plugin cannot be loaded at runtime with the INSTALL PLUGIN statement. This is appropriate for plugins that must be loaded at server startup with the --plugin-load option. The PLUGIN_OPT_NO_UNINSTALL flag indicates that the plugin cannot be unloaded at runtime with the UNINSTALL PLUGIN statement.

    The new member changes the interface, so the plugin interface version, MYSQL_PLUGIN_INTERFACE_VERSION, has been incremented from 0x0102 to 0x0103. Plugins that require access to the new member must be recompiled to use version 0x0103 or higher.

  • A new utility, mysql_plugin, enables MySQL administrators to manage which plugins a MySQL server loads. It provides an alternative to manually specifying the --plugin-load option at server startup or using the INSTALL PLUGIN and UNINSTALL PLUGIN statements at runtime. See mysql_plugin — Configure MySQL Server Plugins.

Bugs Fixed

  • Incompatible Change: The mysql_affected_rows() C API function returned 3 (instead of 2) for INSERT ... ON DUPLICATE KEY UPDATE statements where there was a duplicated key value.

    Now the affected-rows value per row is 1 if the row is inserted as a new row, 2 if an existing row is updated, and 0 if an existing row is set to its current values. If you specify the CLIENT_FOUND_ROWS flag to mysql_real_connect() when connecting to mysqld, the affected-rows value is 1 (not 0) if an existing row is set to its current values. (Bug #46675, Bug #11754979)

  • Incompatible Change: Handling of a date-related assertion was modified.

    However, a consequence of this change is that several functions become more strict when passed a DATE() function value as their argument and reject incomplete dates with a day part of zero. These functions are affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). Because this changes date-handling behavior in General Availability-status series (MySQL 5.1 and 5.5), it was reverted in 5.1.62 and 5.5.21. The change is retained in MySQL 5.6.

    References: See also: Bug #13458237.

  • Performance; InnoDB: This fix improves the performance of operations on VARCHAR(N) columns in InnoDB tables, where N is declared as a large value but the actual string values in the table are short. (Bug #12835650)

  • Performance; InnoDB: The random read-ahead feature that was removed from the InnoDB Plugin is now available again. Because it is only helpful for certain workloads, it is turned off by default. To turn it on, enable the innodb_random_read_ahead configuration option. Because this feature can improve performance in some cases and reduce performance in others, before relying on this setting, benchmark both with and without the setting enabled. (Bug #12356373)

  • InnoDB: The DATA_LENGTH column in the INFORMATION_SCHEMA.TABLES table now correctly reports the on-disk sizes of tablespaces for InnoDB compressed tables. (Bug #12770537)

  • InnoDB: With the configuration settings innodb_file_per_table=1 and innodb_file_format=Barracuda, inserting a column value greater than half the page size, and including that column in a secondary index, could cause a crash when that column value was updated. (Bug #12637786)

  • InnoDB: Unused functions were removed from the internal InnoDB code related to mini-transactions, to clarify the logic. (Bug #12626794, Bug #61240)

  • Replication: Processing of corrupted table map events could cause the server to crash. This was especially likely if the events mapped different tables to the same identifier, such as could happen due to Bug #56226.

    Now, before applying a table map event, the server checks whether the table has already been mapped with different settings, and if so, an error is raised and the slave SQL thread stops. If it has been mapped with the same settings, or if the table is set to be ignored by filtering rules, there is no change in behavior: the event is skipped and IDs are not checked. (Bug #44360, Bug #11753004)

    References: See also: Bug #56226, Bug #11763509.

  • OS X: Compilation failed on OS X 10.7 (Lion) with a warning: Implicit declaration of function 'pthread_init' (Bug #12779790)

  • The metadata locking subsystem added too much overhead for INFORMATION_SCHEMA queries that were processed by opening only .frm or .TRG files and had to scan many tables. For example, SELECT COUNT(*) FROM INFORMATION_SCHEMA.TRIGGERS was affected. (Bug #12828477)

  • With profiling disabled or not compiled in, set_thd_proc_info() unnecessarily checked file name lengths. (Bug #12756017)

    References: This issue is a regression of: Bug #59273.

  • A DBUG_ASSERT added by Bug #11792200 was overly aggressive in raising assertions. (Bug #12537160)

    References: See also: Bug #11792200.

  • CHECK TABLE and REPAIR TABLE failed to find problems with MERGE tables that had underlying tables missing or with the wrong storage engine. Issues were reported only for the first underlying table. (Bug #11754210)

  • (5 DIV 2) and (5.0 DIV 2) produced different results (2 versus 3) because the result of the latter expression was not truncated before conversion to integer. This differed from the behavior in MySQL 5.0 and 5.1. Now both expressions produce 2. (Bug #61676, Bug #12711164)

  • For a lower_case_table_names value of 1 or 2 and a database having a mixed-case name, calling a stored function using a fully qualified name including the database name failed. (Bug #60347, Bug #11840395)

  • SELECT DISTINCT with a deterministic stored function in the WHERE clause could produce incorrect results. (Bug #59736, Bug #11766594)

  • The embedded server crashed when argc = 0. (Bug #57931, Bug #12561297)

  • CREATE TABLE without an ENGINE option determined the default engine at parse rather than execution time. This led to incorrect results if the statement was executed within a stored program and the default engine had been changed in the meantime. (Bug #50614, Bug #11758414)

  • Upgrades using an RPM package recreated the test database, which is undesirable when the DBA had removed it. (Bug #45415, Bug #11753896)