MySQLニュース

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

オリジナル版:http://dev.mysql.com/doc/refman/5.6/en/news-5-6-2.html


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

このリリースの新機能はベータ品質です。他の試作版と同様に、製品レベルのシステムあるいは、重要なデータを持つシステムにインストールする場合は慎重にしてください。

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

http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html


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

http://dev.mysql.com/doc/refman/5.6/en/installing.html


以前のMySQLリリースからアップグレードするには、以下のアップグレードについての注意事項を参照してください。

http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html

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



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

http://dev.mysql.com/downloads/

すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。

バグレポート、バグ修正、パッチ等の情報をお待ちしております。
http://forge.mysql.com/wiki/Contributing

 

5.6.2の全ての「バグフィックス」のリストはオンラインでも閲覧できます
http://dev.mysql.com/doc/refman/5.6/en/news-5-6-2.html

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

D.1.2. Changes in MySQL 5.6.2 (11 April 2011)

    Explicit Partition Selection

      * Partitioning: It is now possible to select one or more
        partitions or subpartitions when querying from a partitioned
        table. In addition, many data modification statements (DELETE,
        INSERT, REPLACE, UPDATE, LOAD DATA, and LOAD XML) that act on
        partitioned tables also now support explicit partition
        selection. For example, assume we have a table named t with
        some integer column named c, and t has 4 partitions named p0,
        p1, p2, and p3. Then the query SELECT * FROM t PARTITION (p0,
        p1) WHERE c < 5 returns rows only in partitions p0 and p1 that
        match the WHERE condition, while partitions p2 and p3 are not
        checked.
        For additional information and examples, see Section 16.5,
        "Partition Selection," as well as the descriptions of the
        statements just listed.

    Row Image Control

      * Replication: Added the binlog_row_image server system
        variable, which can be used to enable row image control for
        row-based replication. This means that you can potentially
        save disk space, network resources, and memory usage by the
        MySQL Server by logging only those columns that are required
        for uniquely identifying rows, or which are actually changed
        on each row, as opposed to logging all columns for each and
        every row change event. In addition, you can use a "noblob"
        mode where all columns, except for unneeded BLOB or TEXT
        columns, are logged.
        For more information, see Section 15.1.3.4, "System variables
        used with the binary log." (Bug #47200, Bug #11755426, Bug
        #47303, Bug #56917, Bug #11755426, Bug #11755513, Bug
        #11764116)

    Crash-Safe Binary Log

      * Replication: Support for checksums when writing and reading
        the binary log is added to the MySQL Server. Writing checksums
        into the binary log is disabled by default; it can be enabled
        by starting the server with the --binlog-checksum option. To
        cause the server to read checksums from the binary log, start
        the server with the --master-verify-checksum option. The
        --slave-sql-verify-checksum option causes the slave to read
        checksums from the relay log.

      * Replication: The MySQL Server now records and reads back only
        complete events or transactions to and from the binary log. By
        default, the server now logs the length of the event as well
        as the event itself and uses this information to verify that
        the event was written correctly to the log. A master also uses
        by default this value to verify events when reading from the
        binary log.
        If you enable writing of checksums (using the binlog_checksum
        system variable), the master can use these instead by enabling
        the master_verify_checksum system variable. The slave I/O
        thread also verifies events received from the master. You can
        cause the slave SQL thread to use checksums (if available) as
        well, when reading from the relay log, by enabling the
        slave_sql_verify_checksum system variable on the slave.

    Slave Log Tables

      * Replication: It is now possible to write information about the
        slave connection to the master and about the slave's execution
        point within the relay log to tables rather than files.
        Logging of master connection information and of slave relay
        log information to tables can be done independently of one
        another; this is controlled by the --master-info-repository
        and --relay-log-info-repository server options. When
        --master-info-repository is set to TABLE, connection
        information is logged in the slave_master_info table in the
        mysql system database. When --relay-log-info-repository is set
        to TABLE, relay log information is logged to the
        slave_relay_log_info table, also in the mysql database.

    Globally Unique Server IDs

      * Replication: Implemented globally unique IDs for MySQL
        servers. A UUID is now obtained automatically when the MySQL
        server starts. The server first checks for a UUID written in
        the auto.cnf file (in the server's data directory), and uses
        this UUID if found. Otherwise, the server generates a new UUID
        and saves it to this file (and creates the file if it does not
        already exist). This UUID is available as the server_uuid
        system variable.
        MySQL replication masters and slaves know each other's UUIDs.
        The value of a slave's UUID can be read on the master as the
        system variable slave_uuid, as well as in the output of SHOW
        SLAVE HOSTS. After a slave is started (with START SLAVE), the
        value of the master's UUID is available on the slave as the
        master_uuid system variable, as well as in the output of SHOW
        SLAVE STATUS.
        For more information, see Section 15.1.3, "Replication and
        Binary Logging Options and Variables." (Bug #33815, Bug
        #11747723)
        See also Bug #16927, Bug #11745543.

    Optimizer Features

      * The optimizer now more efficiently handles queries (and
        subqueries) of the following form:
         SELECT ... FROM single_table ... ORDER BY non_index_column
         [DESC] LIMIT N;
        That type of query is common in web applications that display
        only a few rows from a larger result set. For example:
         SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;
         SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;
        If the sort elements for N rows are small enough to fit in the
        sort buffer, which has a size of sort_buffer_size, the server
        can avoid using a merge file and perform the sort entirely in
        memory. For details, see Section 7.2.1.3, "Optimizing LIMIT
        Queries."

      * The optimizer implements Disk-Sweep Multi-Range Read. Reading
        rows using a range scan on a secondary index can result in
        many random disk accesses to the base table when the table is
        large and not stored in the storage engine's cache. With the
        Disk-Sweep Multi-Range Read (MRR) optimization, MySQL tries to
        reduce the number of random disk access for range scans by
        first scanning the index only and collecting the keys for the
        relevant rows. Then the keys are sorted and finally the rows
        are retrieved from the base table using the order of the
        primary key. The motivation for Disk-sweep MRR is to reduce
        the number of random disk accesses and instead achieve a more
        sequential scan of the base table data. For more information,
        see Section 7.13.10, "Multi-Range Read Optimization."

      * The optimizer implements Index Condition Pushdown (ICP), an
        optimization for the case where MySQL retrieves rows from a
        table using an index. Without ICP, the storage engine
        traverses the index to locate rows in the base table and
        returns them to the MySQL server which evaluates the WHERE
        condition for the rows. With ICP enabled, and if parts of the
        WHERE condition can be evaluated by using only fields from the
        index, the MySQL server pushes this part of the WHERE
        condition down to the storage engine. The storage engine then
        evaluates the pushed index condition by using the index entry
        and only if this is satisfied is base row be read. ICP can
        reduce the number of accesses the storage engine has to do
        against the base table and the number of accesses the MySQL
        server has to do against the storage engine. For more
        information, see Section 7.13.4, "Index Condition Pushdown
        Optimization."

    Performance Schema Notes

      * The Performance Schema has these additions:

           + The Performance Schema now has tables that contain
             summaries for table and index I/O wait events, as
             generated by the wait/io/table/sql/handler instrument:
                o table_io_waits_summary_by_table aggregates table I/O
                  wait events. The grouping is by table.
                o table_io_waits_summary_by_index_usage aggregates
                  table index I/O wait events. The grouping is by
                  table index.
             The information in these tables can be used to assess the
             impact of table I/O performed by applications. For
             example, it is possible to see which tables are used and
             which indexes are used (or not used), or to identify
             bottlenecks on a table when multiple applications access
             it. The results may be useful to change how applications
             issue queries against a database, to minimize application
             footprint on the server and to improve application
             performance and scalability.
             A change that accompanies the new tables is that the
             events_waits_current table now has an INDEX_NAME column
             to identify which index was used for that operation that
             generated the event. The same is true of the
             event-history tables, events_waits_history, and
             events_waits_history_long.

           + The Performance Schema now has an instrument named
             wait/lock/table/sql/handler in the setup_instruments
             table for instrumenting table lock wait events. It
             differs from wait/io/table/sql/handler, which instruments
             table I/O. This enables independent instrumentation of
             table I/O and table locks.
             Accompanying the new instrument, the Performance Schema
             has a table named table_lock_waits_summary_by_table that
             aggregates table lock wait events, as generated by the
             new instrument. The grouping is by table.
             The information in this table may be used to assess the
             impact of table locking performed by applications. The
             results may be useful to change how applications issue
             queries against the database and use table locks, to
             minimize the application footprint on the server and to
             improve application performance and scalability. For
             example, an application locking tables for a long time
             may negatively affect other applications, and the
             instrumentation makes this visible.

           + To selectively control which tables are instrumented for
             I/O and locking, use the setup_objects table. See Section
             19.3.1.2, "Pre-Filtering by Object."

           + The setup_consumers table contents have changed.
             Previously, the table used a "flat" structure with a
             one-to-one correspondence between consumer name and
             destination table. This has been replaced with a
             hierarchy of consumer settings that enable progressively
             finer control of which destinations receive events. The
             previous xxx_summary_xxx consumers no longer exist.
             Instead, the Performance Schema maintains appropriate
             summaries automatically for the levels are which settings
             in the consumer hierarchy are enabled. For example, if
             only the top-level (global) consumer is enabled, only
             global summaries are maintained. Others, such as
             thread-level summaries, are not. See Section 19.3.1.4,
             "Pre-Filtering by Consumer." In addition, optimizations
             have been added to reduce Performance Schema overhead.

           + It is now possible to filter events by object using the
             new setup_objects table. Currently, this table can be
             used to selectively instrument tables, based on schema
             names and/or table names. See Section 19.3.1.2,
             "Pre-Filtering by Object." A new table,
             objects_summary_global_by_type, summarizes events for
             objects.

           + It is now possible to filter events by thread, and the
             Performance Schema collects more information for each
             thread. A new table, setup_actors, can be used to
             selectively instrument user connections, based on the
             user name and/or host name of each connecting session.
             The threads table, which contains a row for each active
             server thread, was extended with several new columns.
             With these additions, the information available in
             threads is like that available from the
             INFORMATION_SCHEMA.PROCESSLIST table or the output from
             SHOW PROCESSLIST. Thus, all three serve to provide
             information for thread-monitoring purposes. Use of
             threads differs from use of the other two thread
             information sources in these ways:
                o Access to threads does not require a mutex and has
                  minimal impact on server performance.
                  INFORMATION_SCHEMA.PROCESSLIST and SHOW PROCESSLIST
                  have negative performance consequences because they
                  require a mutex.
                o threads provides additional information for each
                  thread, such as whether it is a foreground or
                  background thread, and the location within the
                  server associated with the thread.
                o threads provides information about background
                  threads. This means that threads can be used to
                  monitor activity the other thread information
                  sources cannot.
                o You can control which threads are monitored by
                  setting the INSTRUMENTED column or by using the
                  setup_actors table.
             For these reasons, DBAs who perform server monitoring
             using INFORMATION_SCHEMA.PROCESSLIST or SHOW PROCESSLIST
             may wish to monitor using threads instead.

        If you upgrade to this release of MySQL from an earlier
        version, you must run mysql_upgrade (and restart the server)
        to incorporate these changes into the performance_schema
        database.
        For more information, see Chapter 19, "MySQL Performance
        Schema."


    Functionality added or changed:

      * Incompatible Change: The following obsolete constructs have
        been removed. Where alternatives are shown, applications
        should be updated to use them.

           + The FLUSH MASTER and FLUSH SLAVE statements. Use the
             RESET MASTER and RESET SLAVE statements instead.

           + The --log server option and the log system variable.
             Instead, use the --general_log option to enable the
             general query log and the --general_log_file=file_name
             option to set the general query log file name.

           + The --log-slow-queries server option and the
             log_slow_queries system variable. Instead, use the
             --slow_query_log option to enable the slow query log and
             the --slow_query_log_file=file_name option to set the
             slow query log file name.

           + The --one-thread server option. Use
             --thread_handling=no-threads instead.

           + The --skip-thread-priority server option.

           + The engine_condition_pushdown system variable. Use the
             engine_condition_pushdown flag of the optimizer_switch
             variable instead.

           + The have_csv, have_innodb, have_ndbcluster
             (http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-sys
             tem-variables.html#sysvar_have_ndbcluster), and
             have_partitioning system variables. Use SHOW ENGINES
             instead.

           + The sql_big_tables system variable. Use big_tables
             instead.

           + The sql_low_priority_updates system variable. Use
             low_priority_updates instead.

           + The sql_max_join_size system variable. Use max_join_size
             instead.

           + The SLAVE START and SLAVE STOP statements. Use the START
             SLAVE and STOP SLAVE statements instead.

           + The ONE_SHOT modifier for the SET statement.

      * Important Change: Replication: Replication filtering options
        such as --replicate-do-db, --replicate-rewrite-db, and
        --replicate-do-table were not consistent with one another in
        regard to case sensitivity. Now all --replicate-* options
        follow the same rules for case sensitivity applying to names
        of databases and tables elsewhere in the MySQL server,
        including the effects of the lower_case_table_names system
        variable. (Bug #51639, Bug #11759334)

      * Important Change: Replication: Added the MASTER_RETRY_COUNT
        option to the CHANGE MASTER TO statement, and a corresponding
        Master_Retry_Count column to the output of SHOW SLAVE STATUS.
        The option sets the value shown in this column.
        MASTER_RETRY_COUNT is intended eventually to replace the older
        --master-retry-count server option, and is now the preferred
        method for setting the maximum number of times that the slave
        may attempt to reconnect after losing its connection to the
        master. (Bug #44209, Bug #11752887, Bug #44486, Bug #11753110)

      * Important Change: Replication: Added the
        --binlog-rows-query-log-events option for mysqld. Using this
        option causes a server logging in row-based mode to write
        informational rows query log events (SQL statements, for
        debugging and other purposes) to the binary log. MySQL server
        and MySQL programs from MySQL 5.6.2 and later normally ignore
        such events, so that they do not pose an issue when reading
        the binary log. mysqld and mysqlbinlog from previous MySQL
        releases cannot read such events in the binary log, and fail
        if they attempt to do so. For this reason, you should never
        prepare logs for a MySQL 5.6.1 or earlier replication slave
        server (or other reader such as mysqlbinlog) with this option
        enabled on the master. (Bug #11758695, Bug #50935, Bug
        #11758695)

      * Replication: SHOW SLAVE STATUS now displays the actual number
        of retries for each connection attempt made by the I/O thread.
        (Bug #56416, Bug #11763675)

      * Replication: Added the Slave_last_heartbeat status variable,
        which shows when a replication slave last received a heartbeat
        signal. The value is displayed using TIMESTAMP format. (Bug
        #45441)

      * Replication: Timestamps have been added to the output of SHOW
        SLAVE STATUS to show when the most recent I/O and SQL thread
        errors occurred. The Last_IO_Error column is now prefixed with
        the timestamp for the most recent I/O error, and
        Last_SQL_Error shows the timestamp for the most recent SQL
        thread error. The timestamp values use the format YYMMDD
        HH:MM:SS in both of these columns. For more information, see
        Section 12.4.5.35, "SHOW SLAVE STATUS Syntax." (Bug #43535,
        Bug #11752361)

      * Replication: On MySQL replication slaves having multiple
        network interfaces, it is now possible to set which interface
        to use for connecting to the master using the
        MASTER_BIND='interface' option in a CHANGE MASTER TO
        statement.
        The value set by this option can be seen in the Master_Bind
        column of the output from SHOW SLAVE STATUS or the Bind column
        of the mysql.slave_master_info table. (Bug #25939, Bug
        #11746389)

      * Replication: Added the log_bin_basename system variable, which
        contains the complete filename and path to the binary log
        file. (The log_bin system variable shows only whether or not
        binary logging is enabled; log_bin_basename, however, reflects
        the name set with the --log-bin server option.) Also added
        relay_log_basename system variable, which shows the filename
        and complete path to the relay log file.
        See also Bug #19614, Bug #11745759.

      * Changes to replication in MySQL 5.6 make mysqlbinlog output
        generated by the --base64-output=ALWAYS option unusable.
        ALWAYS is now an invalid value for this option. If the option
        is given without a value, the effect is now the same as
        --base64-output=AUTO rather than --base64-output=ALWAYS.
        See also Bug #28760, Bug #11746794.

      * Replication: The SHOW SLAVE STATUS statement now has a
        Master_Info_File field indicating the location of the
        master.info file. (Bug #50316, Bug #11758151)

      * Replication: MySQL now supports delayed replication such that
        a slave server deliberately lags behind the master by at least
        a specified amount of time. The default delay is 0 seconds.
        Use the new MASTER_DELAY option for CHANGE MASTER TO to set
        the delay to N seconds:
         CHANGE MASTER TO MASTER_DELAY = N;
        An event received from the master is not executed until at
        least N seconds later than its execution on the master.
        START SLAVE and STOP SLAVE take effect immediately and ignore
        any delay. RESET SLAVE resets the delay to 0.
        SHOW SLAVE STATUS has three new fields that provide
        information about the delay:

           + SQL_Delay: The number of seconds that the slave must lag
             the master.

           + SQL_Remaining_Delay: When Slave_SQL_Running_State is
             Waiting until MASTER_DELAY seconds after master executed
             event, this field contains the number of seconds left of
             the delay. At other times, this field is NULL.

           + Slave_SQL_Running_State: The state of the SQL thread
             (analogous to Slave_IO_State). The value is identical to
             the State value of the SQL thread as displayed by SHOW
             PROCESSLIST.
        When the slave SQL thread is waiting for the delay to elapse
        before executing an event, SHOW PROCESSLIST displays its State
        value as Waiting until MASTER_DELAY seconds after master
        executed event.
        The relay-log.info file now contains the delay value, so the
        file format has changed. See Section 15.2.2.2, "Slave Status
        Logs." In particular, the first line of the file now indicates
        how many lines are in the file. If you downgrade a slave
        server to a version older than MySQL 5.6, the older server
        will not read the file correctly. To address this, modify the
        file in a text editor to delete the initial line containing
        the number of lines.
        The introduction of delayed replication entails these
        restrictions:

           + Previously the BINLOG statement could execute all types
             of events. Now it can execute only format description
             events and row events.

           + The output from mysqlbinlog --base64-output=ALWAYS cannot
             be parsed. ALWAYS becomes an invalid value for this
             option in 5.6.1.
        For additional information, see Section 15.3.9, "Delayed
        Replication." (Bug #28760, Bug #11746794)

      * The Performance Schema now includes instrumentation for table
        input and output. Instrumented operations include row-level
        accesses to persistent base tables or temporary tables.
        Operations that affect rows are fetch, insert, update, and
        delete. For a view, waits are associated with base tables
        referenced by the view.

      InnoDB Configurable Data Dictionary cache

      * InnoDB Storage Engine: InnoDB now uses the table_cache option
        value as a guide to remove table metadata from memory when
        many different InnoDB tables are accessed. InnoDB table
        metadata is removed using a variation of the LRU algorithm.
        (Parent and child tables in foreign key relationships are
        exempted from removal.) (Bug #20877, Bug #11745884)

      INFORMATION_SCHEMA Table for InnoDB Metrics

      * InnoDB Storage Engine: A new INFORMATION_SCHEMA table,
        INNODB_METRICS, lets you query low-level InnoDB performance
        information, getting cumulative counts, averages, and min/max
        values for internal aspects of the storage engine operation.
        You can start, stop, and reset the metrics counters using the
        configuration variables innodb_monitor_enable,
        innodb_monitor_disable, innodb_monitor_reset, and
        innodb_monitor_reset_all.

      INFORMATION_SCHEMA Tables for InnoDB Buffer Pool Information

      * InnoDB Storage Engine: The new INFORMATION_SCHEMA tables
        INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and
        INNODB_BUFFER_POOL_STATS display InnoDB buffer pool
        information for tuning on large-memory or highly loaded
        systems.

      INFORMATION_SCHEMA Tables for InnoDB Data Dictionary

      * InnoDB Storage Engine: The InnoDB data dictionary, containing
        metadata about InnoDB tables, columns, indexes, and foreign
        keys, is available for SQL queries through a set of
        INFORMATION_SCHEMA tables.

      Persistent InnoDB Optimizer Statistics

      * InnoDB Storage Engine: The optimizer statistics for InnoDB
        tables can now persist across server restarts, producing more
        stable query performance. You can also control the amount of
        sampling done to estimate cardinality for each index,
        resulting in more accurate optimizer statistics.

      * InnoDB Storage Engine: InnoDB can optionally log details about
        all deadlocks that occur, to assist with troubleshooting and
        diagnosis. This feature is controlled by the
        innodb_print_all_deadlocks configuration option. (Bug #1784,
        , Bug #11744783, Bug #17572)

      * InnoDB Storage Engine: A separate InnoDB thread (page_cleaner)
        now handles the flushing of dirty pages that was formerly done
        by the InnoDB master thread.

      * InnoDB Storage Engine: The configuration option
        innodb_purge_threads can now be set to a value higher than 1.

      * InnoDB Storage Engine: The InnoDB kernel mutex has been split
        into several mutexes and rw-locks, for improved concurrency.

      * Windows provides APIs based on UTF-16LE for reading from and
        writing to the console. MySQL now supports a utf16le character
        set for UTF-16LE, so the mysql client for Windows has been
        modified to provide improved Unicode support by using these
        APIs.
        To take advantage of this change, you must run mysql within a
        console that uses a compatible Unicode font and set the
        default character set to a Unicode character set that is
        supported for communication with the server. For instructions,
        see Section 4.5.1.6.1, "Unicode Support on Windows."

      * Several changes were made to optimizer-related system
        variables:

           + The optimizer_switch system variable has new
             engine_condition_pushdown and index_condition_pushdown
             flags to control whether storage engine condition
             pushdown and index condition pushdown optimizations are
             used. The engine_condition_pushdown system variable now
             is deprecated. For information about condition pushdown,
             see Section 7.13.3, "Engine Condition Pushdown
             Optimization," and Section 7.13.4, "Index Condition
             Pushdown Optimization."

           + The optimizer_switch system variable has new mrr and
             mrr_cost_based flags to control use of the Multi-Range
             Read optimization. The optimizer_use_mrr system variable
             has been removed. For information about Multi-Range Read,
             see Section 7.13.10, "Multi-Range Read Optimization."

           + The join_cache_level system variable has been renamed to
             optimizer_join_cache_level. This enables SHOW VARIABLES
             LIKE 'optimizer%' to show more optimizer-related
             settings.

      * In MySQL 5.5, setting optimizer_search_depth to the deprecated
        value of 63 switched to the algorithm used in MySQL 5.0.0 (and
        previous versions) for performing searches. The value of 63 is
        now treated as invalid.


      * The Unicode implementation has been extended to a utf16le
        character set, which corresponds to the UTF-16LE encoding of
        the Unicode character set. This is similar to utf16 (UTF16)
        but is little-endian rather than big-endian.
        utf16le has two collations available:

           + utf16le_general_ci: The default collation, case sensitive
             (similar to utf16_general_ci.

           + utf16le_bin: Case sensitive, with by-codepoint comparison
             that provides the same order as utf16_bin.
        There are some limitations on the use of utf16le. With the
        exception of the item regarding user-defined collations, these
        are the same as the limitations on ucs2, utf16, and utf32.

           + utf16le cannot be used as a client character set, which
             means that it also does not work for SET NAMES or SET
             CHARACTER SET.

           + It is not possible to use LOAD DATA INFILE to load data
             files that use utf16le.

           + FULLTEXT indexes cannot be created on a column that uses
             utf16le. However, you can perform IN BOOLEAN MODE
             searches on the column without an index.

           + The use of ENCRYPT() with utf16le is not recommended
             because the underlying system call expects a string
             terminated by a zero byte.

           + It is not possible to create user-defined UCA collations
             for utf16le because there is no utf16le_unicode_ci
             collation, which would serve as the basis for such
             collations.

      * Unicode collation names now may include a version number to
        indicate the Unicode Collation Algorithm (UCA) version on
        which the collation is based. Initial collations thus created
        use version UCA 5.2.0. For example, utf8_unicode_520_ci is
        based on UCA 5.2.0. UCA-based Unicode collation names that do
        not include a version number are based on version 4.0.0.
        LOWER() and UPPER() perform case folding according to the
        collation of their argument. A character that has uppercase
        and lowercase versions only in a Unicode version more recent
        than 4.0.0 will be converted by these functions only if the
        argument has a collation that uses a recent enough UCA
        version.
        The LDML rules for creating user-defined collations are
        extended to permit an optional version attribute in
        <collation> tags to indicate the UCA version on which the
        collation is based. If the version attribute is omitted, its
        default value is 4.0.0. See Section 9.4.4, "Adding a UCA
        Collation to a Unicode Character Set."

      * Croatian collations were added for Unicode character sets:
        utf8_croatian_ci, ucs2_croatian_ci, utf8mb4_croatian_ci,
        utf16_croatian_ci, and utf32_croatian_ci. Thee collations have
        tailoring for Croatian letters: Č, Ć, Dž,
Ä        They are based on Unicode 4.0.

      * Vietnamese collations were added for the Unicode character
        sets. Those based on Unicode Collation Algorithm 5.2.0 have
        names of the form xxx_vietnamese_520_ci (for example,
        utf8_vietnamese_520_ci). Those based on Unicode Collation
        Algorithm 4.0.0 have names of the form xxx_vietnamese_ci (for
        example, utf8_vietnamese_ci). These collations are the same as
        the corresponding xxx_unicode_520_ci and xxx_unicode_ci
        collations except for precomposed characters which are
        accented versions of "A", "D", "E", "O", and "U". There is no
        change to ideographic characters derived from Chinese. There
        are no digraphs.


      * The Unicode character sets now have a xxx_german2_ci collation
        that provides DIN-2 (phone book) ordering (for example,
        utf8_german2_ci). See Section 9.1.14.1, "Unicode Character
        Sets."

      * The Romansh locale 'rm_CH' is now a permissible value for the
        lc_time_names system variable. (Bug #50915, Bug #11758678)

      * Partitioning: It is now possible to exchange a partition of a
        partitioned table or a subpartition of a subpartitioned table
        with a nonpartitioned table that otherwise has the same
        structure using the ALTER TABLE ... EXCHANGE PARTITION
        statement. This can be used, for example, for importing and
        exporting partitions.
        For more information and examples, see Section 16.3.3,
        "Exchanging Partitions and Subpartitions with Tables."

      * The mysql_upgrade, mysqlbinlog, mysqlcheck, mysqlimport,
        mysqlshow, and mysqlslap clients now have --default-auth and
        --plugin-dir options for specifying which authentication
        plugin and plugin directory to use. (Bug #58139, Bug #11765201)

      * mysqlbinlog now has a --binlog-row-event-max-size option to
        enable large row events to be read from binary log files. (Bug
        #49932)

      * mysqlbinlog now has the capability to back up a binary log in
        its original binary format. When invoked with the
        --read-from-remote-server and --raw options, mysqlbinlog
        connects to a server, requests the log files, and writes
        output files in the same format as the originals. See Section
        4.6.7.3, "Using mysqlbinlog to Back Up Binary Log Files."

      * mysqldump now has an --add-drop-trigger option which adds a
        DROP TRIGGER IF EXISTS statement before each dumped trigger
        definition. (Bug #34325, Bug #11747863)

     * mysqldump --xml now displays comments from column definitions.
        (Bug #13618, Bug #11745324)

     * A new SQL function, WEIGHT_STRING(), returns the weight string
        for an input string. The weight string represents the sorting
        and comparison value of the input string.

     * MySQL distributions now include auth_socket, a server-side
        authentication plugin that authenticates clients that connect
        from the local host through the Unix socket file. The plugin
        uses the SO_PEERCRED socket option to obtain information about
        the user running the client program (and thus can be built
        only on systems that support this option. For a connection to
        succeed, the plugin requires a match between the login name of
        the connecting client user and the MySQL user name presented
        by the client program. For more information, see Section
        5.5.6.1.4, "The Socket Peer-Credential Authentication Plugin."
        (Bug #59017, Bug #11765993)

      * Boolean system variables can be enabled at run time by setting
        them to the value ON or OFF, but previously this did not work
        at server startup. Now at startup such variables can be
        enabled by setting them to ON or TRUE, or disabled by setting
        them to OFF or FALSE. Any other nonnumeric variable is
        invalid. (Bug #46393, Bug #11755200)
        See also Bug #11754743, Bug #51631.

      * Previously, for queries that were aborted due to a sort
        problem, the server wrote the message Sort aborted to the
        error log. Now the server writes more information to provide a
        more specific message, such as:
         Sort aborted: Out of memory (Needed 24 bytes)
         Out of sort memory, consider increasing server sort buffer size
         Sort aborted: Out of sort memory, consider increasing
         server sort buffer size
         Sort aborted: Incorrect number of arguments for FUNCTION
         test.f1; expected 0, got 1
        In addition, if the server was started with --log-warnings=2,
        the server write information about the host, user, and query.
        (Bug #36022, Bug #11748358)

      * Previously, for queries that were aborted due to a sort
        problem or terminated with KILL in the middle of a sort, the
        server wrote the message Sort aborted to the error log. Now
        the server writes more information about the cause of the
        error. These causes include:
         Insufficient disk space in tmpdir prevented tmpfile from
           being created
         Insufficient memory for sort_buffer_size to be allocated
         Somebody ran KILL id in the middle of a filesort
         The server was shutdown while some queries were sorting
         A transaction got rolled back or aborted due to lock wait
           timeout or deadlock
         Unexpected errors, such as source table or even tmp table was
         corrupt processing of a subquery failed which was also sorting
        (Bug #30771, Bug #11747102)

      * The undocumented SHOW NEW MASTER statement has been removed.

      * MySQL distributions now include mysql_clear_password, a
        client-side authentication plugin that sends the password to
        the server without hashing or encryption. Although this is
        insecure, and thus appropriate precautions should be taken
        (such as using an SSL connection), the plugin is useful in
        conjunction with server-side plugins that must have access to
        the original password in clear text. For more information, see
        Section 5.5.6.1.3, "The Clear Text Client-Side Authentication
        Plugin."

      * A new plugin service, my_plugin_log_service, enables plugins
        to report errors and specify error messages. The server writes
        the messages to the error log. See Section 21.2.6, "MySQL
        Services for Plugins."

      * There is now a bind_address system variable containing the
        value of the --bind-address option. This enables the address
        to be accessed at runtime. (Bug #44355, Bug #11752999)

      * "Unknown table" error messages that included only the table
        name now include the database name as well. (Bug #34750, Bug
        #11747993)

      * Previously, EXPLAIN output for a large union truncated the
        UNION RESULT row at the end of the list as follows if the
        string became too large:
         <union1,2,3,4,...>
        To make it easier to understand the union boundaries,
        truncation now occurs in the middle of the string:
         <union1,2,3,...,9>
        (Bug #30597, Bug #11747073)

      * The OpenGIS specification defines functions that test the
        relationship between two geometry values. MySQL originally
        implemented these functions such that they used object
        bounding rectangles and returned the same result as the
        corresponding MBR-based functions. Corresponding versions are
        now available that use precise object shapes. These versions
        are named with an ST_ prefix. For example, Contains() uses
        object bounding rectangles, whereas ST_Contains() uses object
        shapes. For more information, see Section 11.17.5.4.2,
        "Functions That Test Spatial Relationships Between
        Geometries."
        There are also now ST_ aliases for existing spatial functions
        that were already exact. For example, ST_IsEmpty() is an alias
        for IsEmpty() (Bug #4249, Bug #11744883)

      * TO_BASE64() and FROM_BASE64() functions are now available to
        perform encoding to and from base-64 strings.

      * The Block Nested-Loop (BNL) Join algorithm previously used
        only for inner joins has been extended and can be employed for
        outer join operations, including nested outer joins. For more
        information, see Section 7.13.11, "Block Nested-Loop Joins."
        In conjunction with this work, there is a new system variable,
        optimizer_join_cache_level, that controls how join buffering
        is done.

      * A --bind-address option has been added to a number of MySQL
        client programs: mysql, mysqldump, mysqladmin, mysqlbinlog,
        mysqlcheck, mysqlimport, and mysqlshow. This is for use on a
        computer having multiple network interfaces, and enables you
        to choose which interface is used to connect to the MySQL
        server.
    Bugs fixed:

      * Performance: InnoDB Storage Engine: An UPDATE statement for an
        InnoDB table could be slower than necessary if it changed a
        column covered by a prefix index, but did not change the
        prefix portion of the value. The fix improves performance for
        InnoDB 1.1 in MySQL 5.5 and higher, and the InnoDB Plugin for
        MySQL 5.1. (Bug #58912, Bug #11765900)

      * Incompatible Change: When auto_increment_increment is greater
        than one, values generated by a bulk insert that reaches the
        maximum column value could wrap around rather producing an
        overflow error.
        As a consequence of the fix, it is no longer possible for an
        auto-generated value to be equal to the maximum BIGINT
        UNSIGNED value. It is still possible to store that value
        manually, if the column can accept it. (Bug #39828, Bug
        #11749800)

      * Important Change: Partitioning: Date and time functions used
        as partitioning functions now have the types of their operands
        checked; use of a value of the wrong type is now disallowed in
        such cases. In addition, EXTRACT(WEEK FROM col), where col is
        a DATE or DATETIME column, is now disallowed altogether
        because its return value depends on the value of the
        default_week_format system variable. (Bug #54483, Bug
        #11761948)
        See also Bug #57071, Bug #11764255.

      * Important Change: Replication: The CHANGE MASTER TO statement
        required the value for RELAY_LOG_FILE to be an absolute path,
        while the MASTER_LOG_FILE path could be relative.
        The inconsistent behavior is resolved by permitting relative
        paths for RELAY_LOG_FILE, and by using the same basename for
        RELAY_LOG_FILE as for MASTER_LOG_FILE. For more information,
        see Section 12.5.2.1, "CHANGE MASTER TO Syntax." (Bug #12190,
        Bug #11745232)

      * Partitioning: InnoDB Storage Engine: The partitioning handler
        did not pass locking information to a table's storage engine
        handler. This caused high contention and thus slower
        performance when working with partitioned InnoDB tables. (Bug
        #59013)

      * InnoDB Storage Engine: The presence of a double quotation mark
        inside the COMMENT field for a column could prevent a foreign
        key constraint from being created properly. (Bug #59197, Bug
        #11766154)

      * InnoDB Storage Engine: It was not possible to query the
        information_schema.innodb_trx table while other connections
        were running queries involving BLOB types. (Bug #55397, Bug
        #11762763)

      * Partitioning: Failed ALTER TABLE ... PARTITION statements
        could cause memory leaks. (Bug #56380, Bug #11763641)
        See also Bug #46949, Bug #11755209, Bug #56996, Bug #11764187.

      * Replication: When using the statement-based logging format,
        INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE statements
        affecting transactional tables that did not fail were not
        written to the binary log if they did not insert any rows.
        (With statement-based logging, all successful statements
        should be logged, whether they do or do not cause any rows to
        be changed.) (Bug #59338, Bug #11766266)

      * Replication: Formerly, STOP SLAVE stopped the slave I/O thread
        first and then stopped the slave SQL thread; thus, it was
        possible for the I/O thread to stop after replicating only
        part of a transaction which the SQL thread was executing, in
        which case---if the transaction could not be rolled back
        safely---the SQL thread could hang.
        Now, STOP SLAVE stops the slave SQL thread first and then
        stops the I/O thread; this guarantees that the I/O thread can
        fetch any remaining events in the transaction that the SQL
        thread is executing, so that the SQL thread can finish the
        transaction if it cannot be rolled back safely. (Bug #58546,
        Bug #11765563)

      * Replication: mysqlbinlog printed USE statements to its output
        only when the default database changed between events. To
        illustrate how this could cause problems, suppose that a user
        issued the following sequence of statements:
         CREATE DATABASE mydb;
         USE mydb;
         CREATE TABLE mytable (column_definitions);
         DROP DATABASE mydb;
         CREATE DATABASE mydb;
         USE mydb;
         CREATE TABLE mytable (column_definitions);
        When played back using mysqlbinlog, the second CREATE TABLE
        statement failed with Error: No Database Selected because the
        second USE statement was not played back, due to the fact that
        a database other than mydb was never selected.
        This fix insures that mysqlbinlog outputs a USE statement
        whenever it reads one from the binary log. (Bug #50914, Bug
        #11758677)

      * Replication: The --help text for mysqlbinlog now indicates
        that the --verbose (-v) option outputs pseudo-SQL that is not
        necessarily valid SQL and cannot be guaranteed to work
        verbatim in MySQL clients. (Bug #47557, Bug #11755743)

      * An assertion was raised if an XA COMMIT was issued when an XA
        transaction had already encountered an error (such as a
        deadlock) that required the transaction to be rolled back.
        (Bug #59986, Bug #11766788)

      * On some systems, debug builds of comp_err.c could fail due to
        an uninitialized variable. (Bug #59906, Bug #11766729)

      * Attempting to create a spatial index on a CHAR column longer
        than 31 bytes led to an assertion failure if the server was
        compiled with safemutex support. (Bug #59888, Bug #11766714)

      * Aggregation followed by a subquery could produce an incorrect
        result. (Bug #59839, Bug #11766675)

      * The Performance Schema did not update status handler status
        variables, so SHOW STATUS LIKE '%handler%' produced
        undercounted values. (Bug #59799, Bug #11766645)

      * Internally, XOR items partially behaved like functions and
        partially as conditions. This resulted in inconsistent
        handling and crashes. The issue is fixed by consistently
        treating XOR items as functions. (Bug #59793, Bug #11766642)

      * An incorrect character set pointer passed to
        my_strtoll10_mb2() caused an assertion to be raised. (Bug
        #59648, Bug #11766519)

      * DES_DECRYPT() could crash if the argument was not produced by
        DES_ENCRYPT(). (Bug #59632, Bug #11766505)

      * The server and client did not always properly negotiate
        authentication plugin names. (Bug #59453, Bug #11766356)

      * --autocommit=ON did not work (it set the global autocommit
        value to 0, not 1). (Bug #59432, Bug #11766339)

      * mysqldump did not quote database names in ALTER DATABASE
        statements in its output, which could cause an error at reload
        time for database names containing a dash. (Bug #59398, Bug
        #11766310)

      * If filesort fell back to an ordinary sort/merge, it could fail
        to handle memory correctly. (Bug #59331, Bug #11766260)

      * Comparisons of aggregate values with TIMESTAMP values were
        incorrect. (Bug #59330, Bug #11766259)

      * The "greedy" query plan optimizer failed to consider the size
        of intermediate query results when calculating the cost of a
        query. This could result in slowly executing queries when
        there are much faster execution plans available. (Bug #59326,
        Bug #11766256)

      * A query of the following form returned an incorrect result,
        where the values for col_name in the result set were entirely
        replaced with NULL values:
         SELECT DISTINCT col_name ... ORDER BY col_name DESC;
        (Bug #59308, Bug #11766241)

      * The MYSQL_HOME environment variable was being ignored. (Bug
        #59280, Bug #11766219)

      * SHOW PRIVILEGES did not display a row for the PROXY privilege.
        (Bug #59275, Bug #11766216)

      * SHOW PROFILE could truncate source file names or fail to show
        function names. (Bug #59273, Bug #11766214)

      * For DIV expressions, assignment of the result to multiple
        variables could cause a server crash. (Bug #59241, Bug
        #11766191)
        See also Bug #8457, Bug #11745058.

      * MIN(year_col) could return an incorrect result in some cases.
        (Bug #59211, Bug #11766165)

      * With index condition pushdown enabled, a join could produce an
        extra row due to parts of the select condition for the second
        table in the join not being evaluated. (Bug #59186, Bug
        #11766144)

      * DELETE or UPDATE statements could fail if they used DATE or
        DATETIME values with a year, month, or day part of zero. (Bug
        #59173)

      * The ESCAPE clause for the LIKE operator allows only
        expressions that evaluate to a constant at execution time, but
        aggregate functions were not being rejected. (Bug #59149, Bug
        #11766110)

      * Valgrind warnings about uninitialized variables were
        corrected. (Bug #59145, Bug #11766106)

      * Memory leaks detected by Valgrind, some of which could cause
        incorrect query results, were corrected. (Bug #59110, Bug
        #11766075)

      * mysqlslap failed to check for a NULL return from
        mysql_store_result() and crashed trying to process the result
        set. (Bug #59109, Bug #11766074)

      * There was an erroneous restriction on file attributes for LOAD
        DATA INFILE. (Bug #59085, Bug #11766052)

      * SHOW CREATE TRIGGER failed if there was a temporary table with
        the same name as the trigger subject table. (Bug #58996, Bug
        #11765972)

      * The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did
        not work. (Bug #58991, Bug #11765967)

      * In a subquery, a UNION with no referenced tables (or only a
        reference to the virtual table dual) did not allow an ORDER BY
        clause. (Bug #58970, Bug #11765950)

      * OPTIMIZE TABLE for an InnoDB table could raise an assertion if
        the operation failed because it had been killed. (Bug #58933,
        Bug #11765920)

      * If max_allowed_packet was set larger than 16MB, the server
        failed to reject too-large packets with "Packet too large"
        errors. (Bug #58887, Bug #11765878)

      * With index condition pushdown enabled, incorrect results were
        returned for queries on MyISAM tables involving HAVING and
        LIMIT, when the column in the WHERE condition contained NULL.
        (Bug #58838, Bug #11765835)

      * An uninitialized variable for the index condition pushdown
        access method could result in a server crash or Valgrind
        warnings. (Bug #58837, Bug #11765834)

      * A NOT IN predicate with a subquery containing a HAVING clause
        could retrieve too many rows, when the subquery itself
        returned NULL. (Bug #58818, Bug #11765815)

      * Running a query against an InnoDB table twice, first with
        index condition pushdown enabled and then with it disabled,
        could produce different results. (Bug #58816, Bug #11765813)

      * An assertion was raised if a stored routine had a DELETE
        IGNORE statement that failed but due to the IGNORE had not
        reported any error. (Bug #58709, Bug #11765717)

      * WHERE conditions of the following forms were evaluated
        incorrectly and could return incorrect results:
         WHERE null-valued-const-expression NOT IN (subquery)
         WHERE null-valued-const-expression IN (subquery) IS UNKNOWN
        (Bug #58628, Bug #11765642)

      * Issuing EXPLAIN EXTENDED for a query that would use condition
        pushdown could cause mysqld to crash. (Bug #58553, Bug
        #11765570)

      * An OUTER JOIN query using WHERE column IS NULL could return an
        incorrect result. (Bug #58490, Bug #11765513)

      * Starting the server with the --defaults-file=file_name option,
        where the file name had no extension, caused a server crash.
        (Bug #58455, Bug #11765482)

      * Outer joins with an empty table could produce incorrect
        results. (Bug #58422, Bug #11765451)

      * In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...))
        could cause a server crash. (Bug #58371, Bug #11765406)

      * When mysqladmin was run with the --sleep and --count options,
        it went into an infinite loop executing the specified command.
        (Bug #58221, Bug #11765270)

      * Some string manipulating SQL functions use a shared string
        object intended to contain an immutable empty string. This
        object was used by the SQL function SUBSTRING_INDEX() to
        return an empty string when one argument was of the wrong
        datatype. If the string object was then modified by the SQL
        function INSERT(), undefined behavior ensued. (Bug #58165, Bug
        #11765225)

      * Condition pushdown optimization could push down conditions
        with incorrect column references. (Bug #58134, Bug #11765196)

      * injector::transaction did not have support for rollback. (Bug
        #58082, Bug #11765150)

      * Parsing nested regular expressions could lead to recursion
        resulting in a stack overflow crash. (Bug #58026, Bug
        #11765099)

      * The fix for Bug#25192 caused load_defaults() to add an
        argument separator to distinguish options loaded from
        configure files from those provided on the command line,
        whether or not the application needed it. (Bug #57953, Bug
        #11765041)
        See also Bug #11746296.

      * The mysql client went into an infinite loop if the standard
        input was a directory. (Bug #57450, Bug #11764598)

      * If a multiple-table update updated a row through two aliases
        and the first update physically moved the row, the second
        update failed to locate the row. This resulted in different
        errors depending on storage engine, although these errors did
        not accurately describe the problem:

           + MyISAM: Got error 134 from storage engine

           + InnoDB: Can't find record in 'tbl'
        For MyISAM, which is nontransactional, the update executed
        first was performed but the second was not. In addition, for
        two equal multiple-table update statements, one could succeed
        and the other fail depending on whether the record actually
        moved, which is inconsistent.
        Now such an update returns an error if it will update a table
        through multiple aliases, and perform an update that may
        physically more the row in at least one of these aliases. (Bug
        #57373, Bug #11764529, Bug #55385, Bug #11762751)

      * SHOW WARNINGS output following EXPLAIN EXTENDED could include
        unprintable characters. (Bug #57341, Bug #11764503)

      * Outer joins on a unique key could return incorrect results.
        (Bug #57034, Bug #11764219)

      * For a query that used a subquery that included GROUP BY inside
        a < ANY() construct, no rows were returned when there should
        have been. (Bug #56690, Bug #11763918)

      * Some RPM installation scripts used a hardcoded value for the
        data directory, which could result in a failed installation
        for users who have a nonstandard data directory location. The
        same was true for other configuration values such as the PID
        file name. (Bug #56581, Bug #11763817)

      * On FreeBSD and OpenBSD, the server incorrectly checked the
        range of the system date, causing legal values to be rejected.
        (Bug #55755, Bug #11763089)

      * If one connection locked the mysql.func table using either
        FLUSH TABLES WITH READ LOCK or LOCK TABLE mysql.func WRITE and
        a second connection tried to either create or drop a UDF
        function, a deadlock occurred when the first connection tried
        to use a UDF function. (Bug #53322, Bug #11760878)

      * DISTINCT aggregates on DECIMAL UNSIGNED fields could trigger
        an assertion. (Bug #52171, Bug #11759827)

      * On FreeBSD, if mysqld was killed with a SIGHUP signal, it
        could corrupt InnoDB .ibd files. (Bug #51023, Bug #11758773)

      * An assertion could be raised if -1 was inserted into an
        AUTO_INCREMENT column by a statement writing more than one
        row. (Bug #50619, Bug #11758417)

      * A query that contained an aggregate function but no GROUP BY
        clause was implicitly grouped. But implicitly grouped queries
        return zero or one row, so ordering does not make sense. (Bug
        #47853)

      * The parser failed to initialize some internal objects
        properly, which could cause a server crash in the cleanup
        phase after statement execution. (Bug #47511, Bug #11755703)

      * When CASE ... WHEN arguments had different character sets,
        8-bit values could be referenced as utf16 or utf32 values,
        causing an assertion to be raised. (Bug #44793, Bug #11753363)

      * When using ExtractValue() or UpdateXML(), if the XML to be
        read contained an incomplete XML comment, MySQL read beyond
        the end of the XML string when processing, leading to a crash
        of the server. (Bug #44332, Bug #11752979)

      * Bitmap functions used in one thread could change bitmaps used
        by other threads, causing an assertion to be raised. (Bug
        #43152, Bug #11752069)

      * DATE_ADD() and DATE_SUB() return a string if the first
        argument is a string, but incorrectly returned a binary
        string. Now they return a character string with a collation of
        connection_collation. (Bug #31384, Bug #11747221)

      * 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)
        See also Bug #56678, Bug #11763907, Bug #57666.
        This regression was introduced by Bug #39934, Bug #11749859.

      * Incompatible Change: Replication: When determining whether to
        replicate a CREATE DATABASE, DROP DATABASE, or ALTER DATABASE
        statement, database-level options now take precedence over any
        --replicate-wild-do-table options. In other words, when trying
        to replicate one of these statements,
        --replicate-wild-do-table options are now checked if and only
        if there are no database-level options that apply to the
        statement. (Bug #46110, Bug #11754498)

      * Incompatible Change: Starvation of FLUSH TABLES WITH READ LOCK
        statements occurred when there was a constant load of
        concurrent DML statements in two or more connections. Deadlock
        occurred when a connection that had some table open through a
        HANDLER statement tried to update data through a DML statement
        while another connection tried to execute FLUSH TABLES WITH
        READ LOCK concurrently.
        These problems resulted from the global read lock
        implementation, which was reimplemented with the following
        consequences:

           + To solve deadlock in event-handling code that was exposed
             by this patch, the LOCK_event_metadata mutex was replaced
             with metadata locks on events. As a result, DDL
             operations on events are now prohibited under LOCK
             TABLES. This is an incompatible change.

           + The global read lock (FLUSH TABLES WITH READ LOCK) no
             longer blocks DML and DDL on temporary tables. Before
             this patch, server behavior was not consistent in this
             respect: In some cases, DML/DDL statements on temporary
             tables were blocked; in others, they were not. Since the
             main use cases for FLUSH TABLES WITH READ LOCK are
             various forms of backups and temporary tables are not
             preserved during backups, the server now consistently
             allows DML/DDL on temporary tables under the global read
             lock.

           + The set of thread states has changed:
                o Waiting for global metadata lock is replaced by
                  Waiting for global read lock.
                o Previously, Waiting for release of readlock was used
                  to indicate that DML/DDL statements were waiting for
                  release of a read lock and Waiting to get readlock
                  was used to indicate that FLUSH TABLES WITH READ
                  LOCK was waiting to acquire a global read lock. Now
                  Waiting for global read lock is used for both cases.
                o Previously, Waiting for release of readlock was used
                  for all statements that caused an explicit or
                  implicit commit to indicate that they were waiting
                  for release of a read lock and Waiting for all
                  running commits to finish was used by FLUSH TABLES
                  WITH READ LOCK. Now Waiting for commit lock is used
                  for both cases.
                o There are two other new states, Waiting for trigger
                  metadata lock and Waiting for event metadata lock.
        (Bug #57006, Bug #11764195, Bug #54673, Bug #11762116)

      * Incompatible Change: CREATE TABLE statements (including CREATE
        TABLE ... LIKE) are now prohibited whenever a LOCK TABLES
        statement is in effect. (Bug #42546, Bug #11751609)

      * InnoDB Storage Engine: 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
        allow 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 Storage Engine: With binary logging enabled, InnoDB
        could halt during crash recovery with a message referring to a
        transaction ID of 0. (Bug #54901, Bug #11762323)

      * Replication: Due to changes made in MySQL 5.5.3, settings made
        in the binlog_cache_size and max_binlog_cache_size server
        system variables affected both the binary log statement cache
        (also introduced in that version) and the binary log
        transactional cache (formerly known simply as the binary log
        cache). This meant that the resources used as a result of
        setting either or both of these variables were double the
        amount expected. To rectify this problem, these variables now
        affect only the transactional cache. The fix for this issue
        also introduces two new system variables
        binlog_stmt_cache_size and max_binlog_stmt_cache_size, which
        affect only the binary log statement cache.
        In addition, the Binlog_cache_use status variable was
        incremented whenever either cache was used, and
        Binlog_cache_disk_use was incremented whenever the disk space
        from either cache was used, which caused problems with
        performance tuning of the statement and transactional caches,
        because it was not possible to determine which of these was
        being exceeded when attempting to troubleshoot excessive disk
        seeks and related problems. This issue is solved by changing
        the behavior of these two status variables such that they are
        incremented only in response to usage of the binary log
        transactional cache, as well as by introducing two new status
        variables Binlog_stmt_cache_use and
        Binlog_stmt_cache_disk_use, which are incremented only by
        usage of the binary log statement cache.
        For more information, see Section 15.1.3.4, "System variables
        used with the binary log," and Section 5.1.6, "Server Status
        Variables." (Bug #57275, Bug #11764443)

      * Replication: The Binlog_cache_use and Binlog_cache_disk_use
        status variables were incremented twice by a change to a table
        using a transactional storage engine. (Bug #56343, Bug
        #11763611)

      * Replication: When STOP SLAVE is issued, the slave SQL thread
        rolls back the current transaction and stops immediately if
        the transaction updates only tables which use transactional
        storage engines are updated. Previously, this occurred even
        when the transaction contained CREATE TEMPORARY TABLE
        statements, DROP TEMPORARY TABLE statements, or both, although
        these statements cannot be rolled back. Because temporary
        tables persist for the lifetime of a user session (in the
        case, the replication user), they remain until the slave is
        stopped or reset. When the transaction is restarted following
        a subsequent START SLAVE statement, the SQL thread aborts with
        an error that a temporary table to be created (or dropped)
        already exists (or does not exist, in the latter case).
        Following this fix, if an ongoing transaction contains CREATE
        TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements,
        or both, the SQL thread now waits until the transaction ends,
        then stops. (Bug #56118, Bug #11763416)

      * Replication: When an error occurred in the generation of the
        name for a new binary log file, the error was logged but not
        shown to the user. (Bug #46166, Bug #11754544)
        See also Bug #37148, Bug #11748696, Bug #40611, Bug #11750196,
        Bug #43929, Bug# 11752675, Bug #51019, Bug #11758769.

      * Replication: When lower_case_table_names was set to 1 on the
        slave, but not on the master, names of databases in replicated
        statements were not converted, causing replication to fail on
        slaves using case-sensitive file systems. This occurred for
        both statement-based and row-based replication.
        In addition, when using row-based replication with
        lower_case_table_names set to 1 on the slave only, names of
        tables were also not converted, also causing replication
        failure on slaves using case-sensitive file systems. (Bug
        #37656)

      * A Valgrind failure occurred in fn_format when called from
        archive_discover. (Bug #58205, Bug #11765259)

      * Passing a string that was not null-terminated to UpdateXML()
        or ExtractValue() caused the server to fail with an assertion.
        (Bug #57279, Bug #11764447)

      * In bootstrap mode, the server could not execute statements
        longer than 10,000 characters. (Bug #55817, Bug #11763139)

      * NULL values were not grouped properly for some joins
        containing GROUP BY. (Bug #45267, Bug #11753766)

      * A HAVING clause could be lost if an index for ORDER BY was
        available, incorrectly permitting additional rows to be
        returned. (Bug #45227, Bug #11753730)

      * The optimizer could underestimate the memory required for
        column descriptors during join processing and cause memory
        corruption or a server crash. (Bug #42744, Bug #11751763)

      * The server returned incorrect results for WHERE ... OR ...
        GROUP BY queries against InnoDB tables. (Bug #37977, Bug
        #11749031)

      * An incorrectly checked XOR subquery optimization resulted in
        an assertion failure. (Bug #37899, Bug #11748998)

      * A query that could use one index to produce the desired
        ordering and another index for range access with index
        condition pushdown could cause a server crash. (Bug #37851,
        Bug #11748981)

      * With index condition pushdown enabled, InnoDB could crash due
        to a mismatch between what pushdown code expected to be in a
        record versus what was actually there. (Bug #36981, Bug
        #11748647)

      * The range optimizer ignored conditions on inner tables in
        semi-join IN subqueries, causing the optimizer to miss good
        query execution plans. (Bug #35674, Bug #11748263)

      * A server crash or memory overrun could occur with a dependent
        subquery and joins. (Bug #34799, Bug #11748009)

      * Selecting from a view that referenced the same table in the
        FROM clause and an IN clause caused a server crash. (Bug
        #33245)

      * Deeply nested subqueries could cause stack overflow or a
        server crash. (Bug #32680, Bug #11747503)

      * The server crashed on optimization of queries that compared an
        indexed DECIMAL column with a string value. (Bug #32262, Bug
        #11747426)

      * The server crashed on optimizations that used the range
        checked for each record access method. (Bug #32229, Bug
        #11747417)

      * If the optimizer used a Multi-Range Read access method for
        index lookups, incorrect results could occur for rows that
        contained any of the BLOB or TEXT data types. (Bug #30622, Bug
        #11747076)

      * Compared to MySQL 5.1, the optimizer failed to use join
        buffering for certain queries, resulting in slower performance
        for those queries. (Bug #30363, Bug #11747028)

      * For Multi-Range Read scans used to resolve LIMIT queries,
        failure to close the scan caused file descriptor leaks for
        MyISAM tables. (Bug #30221, Bug #11746994)

      * SHOW CREATE DATABASE did not account for the value of the
        lower_case_table_names system variable. (Bug #21317, Bug
        #11745926)

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

      * Replication: The unused and deprecated server options
        --init-rpl-role and --rpl-recovery-rank, as well as the unused
        and deprecated status variable Rpl_status, have been removed.
        (Bug #54649, Bug #11762095)
        See also Bug #34437, Bug #11747900, Bug #34635, Bug #11747961.

      * Replication: The flag stating 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)
        See also Bug #49562, Bug #11757508.

      * The embedded server could crash when determining which
        directories to search for option files. (Bug #55062, Bug
        #11762465)

      * Performance Schema code was subject to a buffer overflow. (Bug
        #53363)

      * On Windows, an IPv6 connection to the server could not be made
        using an IPv4 address or host name. (Bug #52381, Bug
        #11760016)

      * Subquery execution for EXPLAIN could be done incorrectly and
        raise an assertion. (Bug #52317, Bug #11759957)

      * There was a mixup between GROUP BY and ORDER BY concerning
        which indexes should be considered or permitted during query
        optimization. (Bug #52081, Bug #11759746)

      * On Windows, the my_rename() function failed to check whether
        the source file existed. (Bug #51861, Bug #11759540)

      * The ref column of EXPLAIN output for subquery lines could be
        missing information. (Bug #50257, Bug #11758106)

      * Passwords for CREATE USER statements were written to the
        binary log in plaintext rather than in ciphertext. (Bug
        #50172)

      * The BLACKHOLE storage engine failed to load on Solaris and
        OpenSolaris if DTrace probes had been enabled. (Bug #47748,
        Bug #11755909)

      * Some error messages included a literal mysql database name
        rather than a parameter for the database name. (Bug #46792,
        Bug #11755079)

      * In the ER_TABLEACCESS_DENIED_ERROR error message, the command
        name parameter could be truncated. (Bug #45355, Bug #11753840)

      * On Windows, mysqlslap crashed for attempts to connect using
        shared memory. (Bug #31173, Bug #11747181)

      * To forestall the occurrence of possible relocation errors in
        the future, libmysys, libmystrings, and libdbug have been
        changed from normal libraries to "noinst" libtool helper
        libraries, and are no longer installed as separate libraries.
        (Bug #29791, Bug #11746931)

      * A suboptimal query execution plan could be chosen when there
        were several possible range and ref accesses. Now preference
        is given to the keys that match the most parts and choosing
        the best one among them. (Bug #26106, Bug #11746406)

      * Searches for data on a partial index for a column using the
        UTF8 character set would fail. (Bug #24858)

      * For queries with GROUP BY, FORCE INDEX was not ignored as it
        should have been when it would result in a more expensive
        query execution plan. (Bug #18144, Bug #11745649)

MySQLや関連ソリューションに関するお問い合わせ、お見積などがございましたら、ご連絡ください。

お問い合わせ各MySQL保守サービス見積依頼スマートスタイルOSSストア

ページトップへ