MySQL 5.6.7 がリリースされました


MySQL 5.6.7(マイルストーンリリース、リリース候補)は世界でもっともポピュラーなオープンソースデータベースの新バージョンです。


5.6.7はMySQL 5.5の全機能を含んでいます。MySQL 5.6の新機能の概要については、以下の"MySQL 5.6の何が新しくなったのか"を参照してください。

新しいサーバにMySQL 5.6.7をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。


MySQL 5.6.7 RCから以前のリリースへのダウングレードはサポートされていませんのでご注意下さい


MySQL Server 5.6.7は、ダウンロード・ページの「開発版リリース」からソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。


MySQL 5.6向けのプラットフォームリストに注目してください：
- x86(32ビット)とx86_64上のApple Mac OS X 10.6と10.7
(OS X 10.5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のDebian 6
(Debian 5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のRedHat Enterprise / Oracle Linux 5, 6
(RHEL/OL 4はサポート対象からはずされました)
- x86_64上のSuSE Enterprise Linux 11
(SLES 10はサポート対象からはずされました)
- x86(32ビット)とx86_64上のgeneric Linux (kernel 2.6)
- x86_64上のFreeBSD 9
(FreeBSD 7 and 8はサポート対象からはずされました)
- Sparc (64 bit)、x86 (32ビット)、x86_64上のOracle Solaris 10, 11
- x86(32ビット)とx86_64上のWindows Vista, 7, 2008
(Windows XPと2003はサポート対象からはずされました)


オペレーティングシステムのより新しいバージョンを使用するのであれば、バイナリ互換性アプローチ（より古いバージョンのためにビルドされたアプリケーションのサポート）によってMySQL 5.6の使用が保障されるはずです。

WindowsパッケージはWindows Installerのための新しいインストーラ経由、（非インストーラ）ZIPパッケージで利用することができます。以前のMSIパッケージはもはや利用できず、すべてのMySQL製品でWindows向けの統一されたインストーラが利用されるという点に注意してください。



もしプロダクションレベルのシステムでMySQLを稼動させるならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールを含むMySQL Enterprise Editionに注目してください。MySQLのパフォーマンス、セキュリティ、稼働時間を高いレベルで達成します。

D.1.2. Changes in MySQL 5.6.7 (29 September 2012)

   Functionality Added or Changed

     * Important Change: Partitioning: The maximum number of
       partitions for a user-partitioned table is increased from 1024
       to 8192. (Bug #11755685)

     * InnoDB: You can now select the compression level for InnoDB
       zlib. The compression level is controlled by the
       innodb_compression_level configuration option, with a default
       value of 6:

          + Increasing the compression level increases CPU overhead,
            possibly reducing the amount of storage needed for any
            particular row, reducing the possibility of a compression
            failure and subsequent page split.

          + Decreasing the compression level reduces CPU overhead,
            possibly increasing the amount of storage needed for any
            particular row, increasing the possibility of a
            compression failure and subsequent page split.

     * InnoDB: Each data block in an InnoDB compressed table contains
       a certain amount of empty space (padding) to allow DML
       operations to modify the row data without re-compressing the
       new values. Too much padding can increase the chance of a
       compression failure, requiring a page split, when the data
       does need to be re-compressed after extensive changes. The
       amount of padding can now be adjusted dynamically, so that
       DBAs can reduce the rate of compression failures without
       re-creating the entire table with new parameters, or
       re-creating the entire instance with a different page size.
       The associated new configuration options are

     * InnoDB: New information_schema tables, innodb_cmp_per_index
       and innodb_cmp_per_index_reset, provide statistics on InnoDB
       tables that use compression. The statistics at the index level
       let DBAs measure whether the proportion of successful or
       failed compression operations is acceptable for a particular
       combination of table, index, page size, and workload.
       Typically, the compression failure rate should be less than
       10%, particularly when using a compressed table to handle an
       OLTP-style workload with frequent INSERT, UPDATE, or DELETE
       Because gathering those statistics could be very time
       consuming and would hurt performance negatively, the new
       tables are enabled only when the new configuration option
       innodb_cmp_per_index_enabled is set to ON. (It is OFF by

     * When MySQL is configured with -DWITH_SSL=system to build with
       OpenSSL, CMake now produces an error if OpenSSL is older than
       version 1.0.1 (Bug #14167227)

     * The default has changed from false to true for the
       --secure-auth option for mysql and the MYSQL_SECURE_AUTH

     * The WITH_SSL option for CMake now accepts a path_name value
       that indicates the path name to the OpenSSL installation to
       CMake code detects an older or incorrect installed OpenSSL

     * The server now issues a Note diagnostic if an index is created

     * The mysql_clear_password cleartext client-side authentication
       plugin is intended for authentication schemes that require the
       server to receive the password as entered on the client side,
       without hashing. Because the password is sent in the clear,
       this plugin should be used within the context of a secure
       connection, such as an SSL connection, to avoid exposing the
       password over the network. To make inadvertent use of this
       plugin less likely, it is now required that clients explicitly
       enable it. This can be done several ways:

          + Set the LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN environment
            enables the plugin for all client connections.

          + The mysql, mysqladmin, and mysqlslap client programs
            support an --enable-cleartext-plugin option that enables
            the plugin on a per-invocation basis.

          + The mysql_options() C API function supports a
            MYSQL_ENABLE_CLEARTEXT_PLUGIN option that enables the
            uses libmysqlclient and reads option files can enable the
            plugin by including an enable-cleartext-plugin option in
            an option group read by the client library.

     * The unused multi_range_count system variable is now
       deprecated, and will be removed in a future release.

     * The following items are deprecated and will be removed in a
       future MySQL release. Where alternatives are shown,
       applications should be updated to use them.

          + The SHOW PROFILE and SHOW PROFILES statements. Use the
            Performance Schema instead; see Chapter 20, "MySQL
            Performance Schema."

          + The unused date_format datetime_format time_format, and
            max_tmp_tables system variables.

          + The obsolete table. New MySQL 5.6
            installations will no longer create this table. For
            upgrades, mysql_upgrade will check for this table and
            issue a warning about it being deprecated if it is

   Bugs Fixed

     * Performance: InnoDB: The OPTIMIZE TABLE statement now updates
       the InnoDB persistent statistics for that table when
       appropriate. (Bug #14238097)

     * Performance: InnoDB: This fix removes redundant checksum
       validation on InnoDB pages. The checksum was being verified
       uncompressed. Now the verification is only performed when the

     * Performance: InnoDB: Creating large InnoDB log files on a
       Linux system could cause swapping, depending on the size of
       the log files and the available RAM. This fix uses the
       O_DIRECT setting while creating the log files to avoid filling
       up memory buffers with unnecessary data. (Bug #13029546, Bug

     * Performance: Replication: When slave_parallel_workers was
       enabled, an internal multiplier representing the number of
       events above a certain overrun level in the worker queue was
       of; this caused the multiplier to grow without interruption
       over time, leading to a slowdown in event executions on the
       slave. (Bug #13897025)

     * Performance: View definitions (in .frm files) were not cached
       and thus every access to a view involved a file read.
       Definitions now are cached for better performance. (Bug

     * Important Change: Replication: When issued during an ongoing
       transaction, any of the following statements that are used to
       control MySQL Replication now cause the transaction to be

          + CHANGE MASTER TO

          + START SLAVE

          + STOP SLAVE

          + RESET SLAVE
       For more information, see Section 13.3.3, "Statements That
       Cause an Implicit Commit." (Bug #13858841)
       References: See also Bug #14298750, Bug #13627921.

     * Important Change: Formerly, the ExtractValue() and UpdateXML()
       functions supported a maximum length of 127 characters for
       XPath expressions supplied to them as arguments. This

     * Partitioning: InnoDB: A SELECT from a partitioned InnoDB table
       having no primary key sometimes failed to return any rows
       where a nonempty result was expected. In such cases the server
       also returned the error Can't find record in table_name or
       Incorrect key file for table table_name. (Bug #13947868)

     * InnoDB: A race condition could cause assertion errors during a
       DROP TABLE statement for an InnoDB table. Some internal InnoDB
       functions did not correctly determine if a tablespace was
       missing; other functions did not handle the error code
       correctly if a tablespace was missing. (Bug #14251529)

     * InnoDB: With the MySQL 5.6 online DDL feature, an ALTER TABLE
       statement to add a primary key to an InnoDB table could
       succeed, even though the primary key columns contained
       duplicate values. (Bug #14219515)

     * InnoDB: The server could crash with a combination of a
       transaction with SERIALIZABLE isolation level, FLUSH TABLES
InnoDB: Failing assertion: prebuilt->stored_select_lock_type != LOCK_
       (Bug #14222066)

     * InnoDB: The configuration option innodb_max_io_capacity was
       renamed to innodb_io_capacity_max, to emphasize its
       relationship to the existing innodb_io_capacity option. (Bug

     * InnoDB: The server could crash with a signal 8 (division by
       zero error) due to a race condition while computing index
       statistics. (Bug #14150372)

     * InnoDB: The value of the NUMBER_PAGES_CREATED and
       NUMBER_PAGES_WRITTEN columns of the
       incorrect values, and the NUMBER_PAGES_GET column was not
       being set at all. (Bug #13639187)

       operator in a WHERE clause, the next row after the affected
       issue occurred under various isolation levels, such as READ
       COMMITTED and REPEATABLE READ. (Bug #11765218)

     * Partitioning: For tables using PARTITION BY HASH or PARTITION
       BY KEY, when the partition pruning mechanism encountered a
       multi-range list or inequality using a column from the
       partitioning key, it continued with the next partitioning
       column could not be used. This caused partitions which
       possibly matched one or more of the previous partitioning
       columns to be pruned away, leaving partitions that matched
       only the last column of the partitioning key.
       This issue was triggered when both of the following conditions
       were met:

         1. The columns making up the table's partitioning key were
            used in the same order as in the partitioning key
            definition by a SELECT statement's WHERE clause as in the
            column definitions;

         2. The WHERE condition used with the last column of the
            partitioning key was satisfied only by a single value,
            while the condition testing some previous column from the
            partitioning key was satisfied by a range of values.
       An example of a statement creating a partitioned table and a
       query against this for which the issue described above
       occurred is shown here:
  c1 INT,
  c2 INT,
  PRIMARY KEY(c2, c1)

       This issue is resolved by ensuring that partition pruning
       skips any remaining partitioning key columns once a partition

     * Partitioning: The buffer for the row currently read from each
       partition used for sorted reads was allocated on open and
       freed only when the partitioning handler was closed or
       destroyed. For SELECT statements on tables with many
       partitions and large rows, this could cause the server to use
       excessive amounts of memory.
       This issue has been addressed by allocating buffers for reads
       from partitioned tables only when they are needed and freeing
       them immediately once they are no longer needed. As part of
       this fix, memory is now allocated for reading from rows only
       in partitions that have not been pruned (see Section 17.4,
       "Partition Pruning"). (Bug #13025132)
       References: See also Bug #11764622, Bug #14537277.

     * Replication: Updates writing user variables whose values were
       could cause the slave to fail. (Bug #14597605)
       References: This bug was introduced by Bug #14275000.

     * Replication: Using COM_BINLOG_DUMP_GTID with incorrect data
       could cause the server to crash. (Bug #14509140)

     * Replication: An internal routine in the MySQL Replication code
       removed elements from a hash used to store a mapping between
       databases and worker threads at the same time that the hash
       was being iterated over. This could cause an unintended
       reordering of the has elements and thus possibly to incorrect
       results from routines using this hash. (Bug #14381701)
       References: See also Bug #13864642.

     * Replication: The names of the binary log and relay log
       Performance Schema mutexes were mistakenly changed to names
       that differed from the MySQL 5.5 names. The names have been

     * Replication: When setting up replication between a master and
       mysql.slave_master_info table was not updated the first time
       that START SLAVE was issued. (Bug #14298750)
       References: See also Bug #13858841.

     * Replication: The --disable-gtid-unsafe-statements option
       caused any nontransactional DML statement involving temporary
       tables to be rejected with an error even with binlog_format
       nontransactional tables affected by the statements are also
       temporary tables. (Bug #14272627)

     * Replication: When using multithreaded slaves,
       databases to slave worker threads, which could cause
       statements to be executed out of order when this option was
       used. This could result in a slave that was inconsistent with
       the master. (Bug #14232958)

     * Replication: mysql_upgrade failed when the server was running
       the MySQL system tables are stored using MyISAM. This problem
       is fixed by changing the default logging behavior for
       mysql_upgrade; logging is now disabled by default. (Actions
       taken by mysql_upgrade depend on the server version, and thus
       can execute mysql_upgrade using the --write-binlog option.
       (Bug #14221043, Bug #13833710)

     * Replication: The initialization and usage of a number of
       internal programming objects relating to GTIDs did not work
       properly with PERFORMANCE_SCHEMA. (Bug #14152637)

     * Replication: The scheduler for multi-threaded slaves did not
       take into account databases implicitly involved in operations
       through foreign key dependencies, which could lead to a
       temporary loss of consistency on the slave. To avoid this
       problem, replication events on the master that invoke foreign
       key relationships between table is different databases are now
       marked in such a way that they can be scheduled sequentially
       to avoid race conditions and thereby inconsistency. However,
       this can adversely affect performance. (Bug #14092635)

       4G for the max_binlog_cache_size and
       max_binlog_stmt_cache_size system variables were truncated to
       file larger than 4G in size, even when max_binlog_cache_size

     * Replication: It was possible for the multithreaded slave
       coordinator to leak memory when the slave was stopped while
       waiting for the next successful job to be added to the worker
       queue. (Bug #13635612)

     * Replication: The Master_id column of the
       mysql.slave_master_info and mysql.slave_relay_log_info tables
       showed the slave's server ID instead of the master's server
       ID. (Bug #12344346)

     * Replication: Statements such as UPDATE ... WHERE
       primary_key_column = constant LIMIT 1 are flagged as unsafe
       for statement-based logging, despite the fact that such
       statements are actually safe. In cases where a great many such
       statements were run, this could lead to disk space becoming
       exhausted do to the number of such false warnings being
       logged. To prevent this from happening, a warning suppression
       mechanism is introduced. This warning suppression acts as
       follows: Whenever the 50 most recent
       ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more
       enabled. When activated, this causes such warnings not to be
       warning was repeated N times in last S seconds. This continues
       seconds or less; once the number of warnings has decreased
       below this threshold, the warnings are once again logged
       The fix for this issue does not affect how these warnings are
       reported to MySQL clients; a warning is still sent to the
       client for each statement that generates the warning. This fix
       also does not make any changes in how the safety of any
       statement for statement-based logging is determined. (Bug
       #11759333, Bug #51638)
       References: See also Bug #11751521, Bug #42415.

     * ALTER TABLE ... DROP FOREIGN KEY that did not name the foreign
       name is required. (Bug #14530380)

     * In-place ALTER TABLE operations for InnoDB tables could raise

     * mysql_secure_installation did not work if old_passwords was

     * Polygons with holes could cause a server crash for spatial
       operations. (Bug #14497827)

     * For complex conditions, the optimizer could produce an
       incorrect range construction and return incorrect query
       results. (Bug #14497598)

     * Item_cache_str::save_in_field() dereferenced a null pointer if
       the cached value was NULL. (Bug #14501403)

     * The optimizer could raise an assertion when grouping and
       sorting in descending order on an indexed column. (Bug

     * A query with GROUP BY ... WITH ROLLUP comparing a grouping
       column using the IN operator caused an assertion to be raised.
       (Bug #14500792)

     * In debug builds, with semi-join enabled, GROUP BY ... WITH
       ROLLUP that did not use a temporary table could cause a server
       crash. (Bug #14499409)

     * An assertion was raised when using the join cache for a query
       that contained an IN subquery query with a subquery that is
       expected to return a single row but returned more than one.
       (Bug #14499331)

     * In mysql_com.h, the CLIENT_CONNECT_ATTRS and
       CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA symbols incorrectly were
       defined as the same value. (Bug #14482472)

     * The Threads_running status variable was not updated properly.
       (Bug #14471011)

       caused a server crash. (Bug #14468106)

     * With a password policy of STRONG and a password of 100
       characters or more, VALIDATE_PASSWORD_STRENGTH() could cause a
       server crash. (Bug #14458293)

     * PASSWORD(NULL) and OLD_PASSWORD(NULL) could cause a server
       crash. (Bug #14458217)

     * The explicit_defaults_for_timestamp system variable was not
       possible to make runtime decisions based on its value. (Bug

     * An ALTER TABLE for an InnoDB table that attempted to add an
       index and also change the nullability of a column
       participating in that index raised an assertion. (Bug

     * For debug builds, if one session used a DDL statement to alter
       an InnoDB table, another session could raise an assertion
       failure if it had a pre-alter consistent snapshot of the
       table. (Bug #14365043)

     * The --server-public-key option for mysql and mysqltest has
       refers to a file and for consistency with related server-side
       variable naming. Also, this option now is available only if
       MySQL was built with OpenSSL (not yaSSL) because yaSSL does
       not support the necessary RSA encryption. (Bug #14348721)

     * The result set could contain extra rows for queries on MyISAM
       tables that used the SQL_BUFFER_RESULT modifier and a
       subquery. (Bug #14348858)

       binaries, before packaging them. (Bug #14318456)

     * Inside a stored program, references to stored program
       variables in XML functions such as ExtractValue() failed after

     * The Performance Schema used listed the nanosecond timer by
       default for stages and statements in the setup_timers table.
       Now the idle, stage, and statement timers used the preferred
       timers if they are available, but alternate timers if not.
       (Bug #14298586)

     * Some queries for which the optimizer used index condition
       pushdown in conjunction with ref access could be very slow if

     * A LooseScan semi-join could return duplicate rows from the
       outer table. (Bug #14271594)

     * Queries executed using MaterializeScan semi-join strategy and
       a materialized subquery could return too many rows. (Bug

     * The Performance Schema generated different digests for a
       statement before and after selecting a database. (Bug

     * The Performance Schema digest-generation code could fail with
       a race condition. (Bug #14250296)


     * An optimizer trace could crash attempting to print freed
       subquery items. (Bug #14238404)

     * With semi-join optimization enabled, subqueries in the WITH
       CHECK OPTION clause of view definitions were evaluated
       incorrectly. (Bug #14230177)

       server name caused a server crash. (Bug #14220942)

     * If a call to socket() failed, the Performance Schema created
       instrumentation for it anyway. (Bug #14209598)

     * REQUIRE ISSUER clauses for GRANT statements were not rewritten
       properly for logging and caused a server crash. (Bug

     * WEIGHT_STRING() could crash if given a bad flags argument.
       (Bug #14211236)

       not acquire a sufficiently strong metadata lock to prevent a
       concurrent ALTER TABLE statement with ADD or DROP from
       modifying the tablespace. This could result in warnings or
       raise an assertion. (Bug #14213236)

     * Some queries with a HAVING clause with a function that
       referred to a function in the WHERE list with a subquery as

     * String allocation could cause Valgrind warnings. (Bug

     * For queries that used range access, the optimizer could read
       uninitialized data, resulting in Valgrind warnings. (Bug

     * mysql_upgrade did not set the STATS_PERSISTENT=0 table option

     * In debug builds, the optimizer raised an unnecessary (too

     * Join processing could attempt to clean up a temporary table

     * For JSON-format EXPLAIN statements, derived tables were not

     * Incorrect internal conversion of string-format dates could
       cause a server crash. (Bug #14167911)

     * In debug builds, comparisons for strings that had the
       ucs2_unicode_520_ci collation could raise an assertion. (Bug

     * In-place ALTER TABLE did not work for a table with a GEOMETRY
       column, even if the alteration did not involve that column.
       (Bug #14140927)

     * For nonexistent files, the Performance Schema file I/O
       instrumentation sometimes did extra work or was subject to
       instrumentation leaks. (Bug #14113704)

     * Small sort_buffer_size values could result in a server crash.
       (Bug #14111180)

     * Within a trigger, references to a temporary table used during
       the query execution process could end up pointing to
       nonexisting fields on subsequent executions, causing a server
       crash. (Bug #14105951)

     * Negative values could be erroneously reported for some columns
       in the buffer_pool_pages_in_flush row in the
       information_schema.innodb_metrics table. (Bug #14090287)

     * The FirstMatch strategy for semi-joins produced incorrect
       results for some queries with multiple inner tables. (Bug

     * JSON-format EXPLAIN statements could raise an assertion or
       cause the server to hang for statements with an
       impossible-WHERE clause and subqueries in ORDER BY or GROUP BY
       clauses. (Bug #14084642)

     * With materialization and semi-joins enabled, some queries with
       an OR condition could produce incorrect results. (Bug

     * Improper error handling for CREATE SERVER, DROP SERVER, and
       ALTER SERVER could raise an assertion. (Bug #14061851)

     * RELEASE SAVEPOINT did not have sufficient checks for the XA
       transaction state to prevent a savepoint from being released

     * The libmysqlclient_r client library exported symbols from
       yaSSL that conflict with OpenSSL. If a program linked against
       that library and libcurl, it could crash with a segmentation
       fault. (Bug #14068244)

     * In-place ALTER TABLE did not handle autopartitioning storage
       engines such as NDB. (Bug #14063233)

     * Improper initialization by spatial functions could cause a
       server crash the first time they were invoked following server
       startup. (Bug #14015762)

     * For JSON-format EXPLAIN statements, improper handling of
       subqueries could cause an assertion to be raised. (Bug

     * SELECT on a partitioned table that used a join buffer could
       cause a server crash. (Bug #13949549)

     * Polygon sorting by spatial functions could be done incorrectly
       and cause a server crash. (Bug #13938850)

     * For DELETE statements, WHERE clause row retrieval that should
       access only the index tree could raise an assertion. (Bug

       was given by a placeholder in a prepared statement, the server

     * Some arguments could cause ST_Buffer() to crash. (Bug
       #13832749, Bug #13833019)

     * Queries that used the ST_Contains and Within() functions
       yielded incorrect results when argument columns had a spatial
       index. (Bug #13813064)

     * CHECK TABLE and REPAIR TABLE could crash if a key definition
       server produces an error. (Bug #13555854)

     * The optimizer used a full index scan for cases for which a
       loose index scan was preferable. (Bug #13464493)
       References: This bug is a regression of Bug #12540545.

     * COUNT(DISTINCT(SELECT 1)) could be evaluated incorrectly if
       the optimizer used a loose index scan. (Bug #13444084)

     * A query for a FEDERATED table could return incorrect results
       when the underlying table had a compound index on two columns

     * mysqlhotcopy failed for databases containing views. (Bug
       #62472, Bug #13006947, Bug #12992993)

     * "Illegal mix of collation" errors were returned for some
       operations between strings that should have been legal. (Bug
       #64555, Bug #13812875)

     * The ST_Contains() and Within() functions yielded an incorrect
       #65348, Bug #14096685)

     * If the server was started with secure_auth disabled, it did
       #65462, Bug #14136937)

     * The GeomFromWKB() function did not return NULL if the SRID

     * With statement-based binary logging, stored routines that
       accessed but did not modify tables took too strong a lock for
       the tables, unnecessarily blocking other statements that also

     * For some queries, the optimizer used index_merge access method

     * In prepared statements, MYSQL_TYPE_DATE parameters when
       converted to an integer were handled as MYSQL_TYPE_DATETIME
       values and the conversion produced incorrect results. (Bug
       #64667, Bug #13904869)


     * In-place ALTER TABLE incorrectly handled indexes using key

     * Starting the server with --bind-address=* is supposed to cause
       the server to accept TCP/IP connections on all server host
       IPv6 and IPv4 interfaces if the server host supports IPv6, or
       TCP/IP connections on all IPv4 addresses otherwise. But the
       server sometimes did not correctly detect when IPv6 was not

     * Internal temporary MyISAM tables were unnecessarily registered

     * Queries with ALL over a UNION could return an incorrect result

     * In debug builds, an InnoDB assertion was overly aggressive

       BY could cause the optimizer to choose an incorrect index for
       #54599, Bug #11762052)

     * ALTER TABLE operations that changed a column definition could
       cause a loss of referential integrity for columns in a foreign
       key. (Bug #46599, Bug #11754911)

     * mysqlbinlog did not accept input on the standard input when

     * There was a performance regression for queries that used GROUP

     * mysqldump could dump views and the tables on which they depend
       in such an order that errors occurred when the dump file was
       reloaded. (Bug #44939, Bug #11753490)

     * The ALTER USER statement cleared the user password in the
       mysql.user table. It no longer does this.