MySQL 5.7 Release Notes
This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)
Important Change; Microsoft Windows: MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)
Important Change: The atomic-operations API was simplified to use only the existing GCC built-in implementation or platform-provided implementations (for Windows, Solaris), and to remove the custom mutex-based fallback implementation. The retained implementations are those able to use CPU-native atomics. This simplifies the atomics APIs and related code and deals with bugs resulting from the fallback implementation.
        As part of this work, the (undocumented)
        WITH_ATOMIC_LOCKS and
        MY_ATOMIC_MODE_RWLOCKS CMake
        options were removed.
      
On platforms where native atomics are supported, this change introduces no issues. For other platforms, here are potential MySQL compilation issues, and solutions:
            32-bit Linux variants that use GCC 4.1 will no longer work.
            This includes Red Hat 5, which is a supported platform. The
            solution to this problem is to use a new GCC or set the
            -march compiler option. For example, use
            GCC 4.4, which is available on Red Hat 5. For information
            about specifying compiler options, see
            Compiler Flags.
          
There may be issues on unsupported platforms. For example, 64-bit PowerPC, 32-bit ARM, and 64-bit ARM will not compile with older compilers. The solution for these cases is to use GCC 4.7 or later.
(WL #7655)
        CMake now checks for minimum versions of
        supported compilers: gcc 4.4 (Linux,
        Solaris); Sun Studio 12u2 (Solaris client library); Clang 3.3
        (OS X, FreeBSD). This check can be disabled with the
        -DFORCE_UNSUPPORTED_COMPILER=ON
        option.
       (Bug #19187034)
Noisy compiler warnings on FreeBSD 10 were silenced. (Bug #18790490)
CMake workarounds for older OS X and XCode versions were removed. On OS X, compilation always uses Clang, even for 32-bit builds.
Compilation on OS X is now supported for OS X 10.8 and up, using XCode 5 and up. Compilation on older versions may work but is unsupported. (Bug #18510941)
        Previously, the
        MYSQL_MAINTAINER_MODE
        CMake option was turned on by default for
        debug builds and off for release builds, and
        MYSQL_MAINTAINER_MODE caused
        -Werror to be enabled when building with GCC.
        This made it cumbersome to enable -Werror under
        certain conditions, such as when compiling with Clang.
      
        Now, MYSQL_MAINTAINER_MODE is on by default
        when compiling debug builds with GCC, and
        MYSQL_MAINTAINER_MODE enbles
        -Werror regardless of whether GCC or Clang is
        used. Enabling -Werror with Clang can be done
        simply by explicitly setting
        -DMYSQL_MAINTAINER_MODE=1 when running
        CMake. In addition, some compilation warnings
        reported by Clang 3.4 were fixed, making it possible to build
        the default debug build with -Werror.
       (Bug #18313717)
Build support was modified to produce the same warnings for Clang as for gcc. (Bug #17959689)
Work was done to clean up the source code base, including: Removing unneeded CMake checks; removing unused macros from source files; reorganizing header files to reduce the number of dependencies and make them more modular, removing function declarations without definitions, replacing locally written functions with equivalent functions from industry-standard libraries.
Incompatible Change: mysql_install_db has been rewritten from Perl into C++. This enables it to be provided as an executable binary and eliminates its dependency on having Perl installed.
The new implementation involves several other differences as well. The following items list some of the most significant changes. For more information, see mysql_install_db — Initialize MySQL Data Directory.
            The executable binary version is located in the
            bin installation directory, whereas the
            Perl version was located in the scripts
            installation directory. For upgrades from an older version
            of MySQL, you may find a version of
            mysql_install_db in both directories. To
            avoid confusion, remove the version from the
            scripts directory. For fresh
            installations of MySQL 5.7.5 or later,
            mysql_install_db is only found in the
            bin directory, and the
            scripts directory is no longer present.
            Applications that expect to find
            mysql_install_db in the
            scripts directory should be updated to
            look in the bin directory instead.
          
            Some options are handled differently. For example, the
            --datadir option is
            mandatory.
          
            There are several new options. For example, there are
            options that afford explicit control over the administrative
            account that is created. By default, this is
            'root'@'localhost', but you can use
            --admin-user and
            --admin-host to
            change the user and host parts of the account name.
          
            Several options have been removed or replaced. For example,
            --skip-random-passwords has been replaced
            by --insecure.
          
            mysql_install_db always overwrites the
            .mysql_secret file, rather than
            appending to it if it exists. It is assumed that immediately
            after installation, you will connect to the server using the
            file contents and reset the administrative password before
            proceeding to another deployment.
          
            mysql_install_db no longer passes
            unrecognized options to mysqld. (But you
            can use
            --defaults-extra-file
            to specify an option file to be added to the
            mysqld bootstrapping command.)
          
            mysql_install_db no longer creates a
            default my.cnf file.
          
(WL #7688)
Incompatible Change: 
        In MySQL 5.6.6, the YEAR(2) data
        type was deprecated. Support for
        YEAR(2) has now been removed.
        Once you upgrade to MySQL 5.7.5 or newer, any remaining
        YEAR(2) columns must be converted
        to YEAR(4) to become usable
        again. For conversion strategies, see
        2-Digit YEAR(2) Limitations and Migrating to 4-Digit YEAR. For example, run
        mysql_upgrade after upgrading.
       (WL #6263)
Incompatible Change: 
        The InnoDB storage engine can no longer be
        disabled. The
        --skip-innodb
        option is deprecated and has no effect, and its use results in a
        warning. It will be removed in a future MySQL version. This also
        applies to its synonyms (--innodb=OFF,
        --disable-innodb, and so forth).
      
        A new innodb_lock_no_retry flag for the
        --debug option is now available.
        --debug='d,innodb_lock_no_retry' causes
        InnoDB to fail immediately during startup if
        locks cannot be acquired, rather than making 100 attempts before
        failing. This may be useful during testing or debugging to
        produce faster server exit when InnoDB cannot
        acquire its locks.
      
        One reason for disabling InnoDB is to enable
        starting a server instance using the same data directory as an
        existing instance. (MyISAM permits that, but
        InnoDB does not.) Because
        InnoDB can no longer be disabled, the
        workaround is to stop the existing instance before starting
        another so that there is only one active instance using a data
        directory at a time.
       (WL #7976)
        The deprecated timed_mutexes system variable
        has been removed.
       (Bug #18277305, WL #7436)
The deprecated mysqlhotcopy utility has been removed from MySQL distributions. Alternatives include mysqldump and MySQL Enterprise Backup. (WL #7854)
The deprecated mysqlbug, mysql_waitpid, and mysql_zap utilities have been removed from MySQL distributions. (WL #7689, WL #7826)
        The deprecated storage_engine system variable
        has been removed. Use
        default_storage_engine instead.
       (WL #7148)
MySQL now includes DTrace support on Oracle Linux 6 or higher with UEK kernel. If DTrace is present, server builds will detect it with no special CMake options required. For information about using DTrace on MySQL, see Tracing mysqld Using DTrace. (WL #7894)
        The server was made more consistent and resilient with regard to
        handling of statements for which the IGNORE
        keyword is specified.
      
            The server failed to report warnings for INSERT
            IGNORE statements.
          
            The server could fail to report warnings for multiple-table
            DELETE IGNORE statements.
          
            UPDATE triggers for a table were invoked
            even for UPDATE IGNORE statements for
            which a unique index caused the update to be ignored.
          
            For debug builds, an assertion could be raised for errors
            occurring in DELETE IGNORE statements.
          
            For debug builds, an assertion could be raised for deadlocks
            resulting from DELETE IGNORE statements.
          
            For DELETE IGNORE executed on the parent
            table in a foreign key relationship, foreign key violation
            errors were treated as warnings (correct), but rows that did
            not produce foreign key violations were not deleted.
          
The server was made more consistent and resilient with regard to handling of statements in strict SQL mode.
In strict SQL mode, triggers could permit operations not permitted in strict mode.
In strict SQL mode, deprecation warnings about duplicate indexes were incorrectly promoted to errors.
            Strict SQL mode was not applied to multiple-table
            DELETE statements.
          
        For more information about IGNORE and strict
        SQL mode, see Comparison of the IGNORE Keyword and Strict SQL Mode.
       (Bug #6196, Bug #11744960, Bug #43895, Bug #11752648, Bug #68726, Bug #16522924, Bug #16860715, Bug #16860829, Bug #14786621, Bug #17550423, Bug #42910, Bug #11751889, Bug #16976939, Bug #18526888, WL #6614, WL #6891)
Incompatible Change: 
        A new log record type (MLOG_FILE_NAME) is
        used to identify file-per-table tablespaces that have been
        modified since the last checkpoint. This enhancement simplifies
        tablespace discovery during crash recovery and eliminates scans
        on the file system prior to redo log application. For more
        information about the benefits of this enhancement, see
        Tablespace Discovery During Crash Recovery.
      
This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5. (WL #7142, WL #7806)
The optimizer computes more accurate costs for semijoin materialization. (Bug #18558561)
        Optimizer trace output for range access in the
        considered_access_path section has been
        improved: Instead of always printing "access_type":
        "ref" for index lookup types,
        "eq_ref", "ref", or
        "fulltext" is now printed.
       (Bug #18195373)
        During query execution plan construction, the optimizer now can
        use condition filtering to better use conditions on a table in
        estimating the number of qualifying rows to join to the next
        table. For example, even though there might be an index-based
        access method that can be used to select rows from the current
        table in a join, there might also be additional conditions for
        the table in the WHERE clause that can filter
        (further restrict) the estimate for qualifying rows passed to
        the next table.
      
        To control whether the optimizer considers additional filtering
        conditions, use the
        condition_fanout_filter flag
        of the optimizer_switch system
        variable. This flag is enabled by default but can be disabled to
        suppress condition filtering (for example, if a particular query
        is found to yield better performance without it).
      
For more information, see Condition Filtering. (WL #6635)
        The optimizer now uses more exact index statistics. Currently,
        the improved values are used by InnoDB, with
        these effects:
      
In many cases, better execution plans result for queries for which previously a less optimal join index or table join order was chosen.
            The row estimates in EXPLAIN
            output are more accurate, as well as the filter values in
            some cases.
          
            Cardinality estimates in the index statistics displayed by
            SHOW INDEX are more accurate
            for InnoDB tables.
          
(WL #7339)
To generate execution plans, the optimizer uses a cost model that is based on estimates of the cost of various operations that occur during query execution. The optimizer has a set of compiled-in default “cost constants” available to it to make decisions regarding execution plans.
        The optimizer now also has a database of cost estimates to use
        during execution plan construction. These estimates are stored
        in the server_cost and
        engine_cost tables in the
        mysql system database and are configurable at
        any time: Any non-NULL cost estimate stored
        in the cost model tables overrides the corresponding compiled-in
        default estimate. Any NULL estimate indicates
        to the optimizer to use the compiled-in default.
      
Implementation and testing is ongoing to make it safe for DBAs to change these values. Currently, changing them should be considered at your own risk.
        There is also a new FLUSH
        variant, FLUSH OPTIMIZER_COSTS, that causes
        the server to re-read the cost tables and apply any changed
        estimates to new sessions.
      
For more information, see The Optimizer Cost Model.
        If you upgrade to this MySQL release from an earlier version,
        you must run mysql_upgrade (and restart the
        server) to incorporate these changes into the
        mysql database.
       (WL #6564, WL #6589, WL #7276, WL #7315, WL #7316)
Incompatible Change: 
        The Performance Schema now provides a
        user_variables_by_thread table that
        exposes user-defined variables. For more information, see
        Performance Schema User-Defined Variable Tables.
      
        In consequence of this change, the server now limits
        user-defined variable names to a maximum of 64 characters, the
        length of the VARIABLE_NAME column in the
        table. Previously, the server did not enforce a limit. The new
        limit is similar to the limit on the lengths of many other
        identifiers in MYSQL (see User-Defined Variables).
        Queries that use very long user-defined variable names must be
        rewritten to user shorter names.
      
        If you upgrade to this MySQL release from an earlier version,
        you must run mysql_upgrade (and restart the
        server) to incorporate this change into the
        performance_schema database.
       (WL #6884)
        Previously, for the wait event tables (such as
        events_waits_current), the
        NUMBER_OF_BYTES column was
        NULL for table I/O waits; that is, for events
        for the wait/io/table/sql/handler instrument.
        For table I/O waits, this value now indicates the number of rows
        processed.
      
        In addition, for batch I/O operations (such as row fetches for
        table or index scans), the Performance Schema now can report a
        single event for N rows, rather than
        reporting a single-row event N times.
        This change significantly reduces Performance Schema overhead
        for table batch I/O by reducing the number of reporting calls.
        The tradeoff is lesser accuracy for event timing. Rather than
        time for an individual row operation as in per-row reporting,
        timing for batch I/O includes time spent for operations such as
        join buffering, aggregation, and returning rows to the client.
      
        For more information on the conditions under which batch I/O
        reporting occurs, see the description of the
        NUMBER_OF_BYTES column in
        The events_waits_current Table.
       (WL #7802)
        The Performance Schema stage event tables
        (events_stages_current,
        events_stages_history, and
        events_stages_history_long) contain
        two new columns that, taken together, provide a stage progress
        indicator for each row:
      
            WORK_COMPLETED: The number of work units
            completed for the stage
          
            WORK_ESTIMATED: The number of work units
            expected for the stage
          
        Each column is NULL if no progress
        information is provided for an instrument. Interpretation of the
        information, if it is available, is entirely up to the
        instrument implementation. Initially, to demonstrate the
        concept, the stage/sql/copy to tmp table
        instrument provides progress information if it is enabled. In
        this case, the unit for interpretation of the columns is number
        of rows copied.
      
For more information, see Performance Schema Stage Event Tables.
        If you upgrade to this MySQL release from an earlier version,
        you must run mysql_upgrade (and restart the
        server) to incorporate this change into the
        performance_schema database.
       (WL #7414)
Incompatible Change: MySQL 5.6 deprecated passwords that used the older pre-4.1 password hashing format. Support for these passwords is now removed, which involves the following changes. Applications that use any feature no longer supported must be modified.
            The server-side mysql_old_password
            authentication plugin is removed. Accounts that use this
            plugin are disabled at startup and the server writes an
            “unknown plugin” message to the error log. For
            instructions on upgrading accounts that use this plugin, see
            Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin.
          
            The client-side mysql_old_password
            authentication plugin is removed from the C client library.
          
            The --secure-auth option to the server and
            client programs is the default, but is now a no-op. It is
            deprecated and will be removed in a future MySQL version.
          
            The --skip-secure-auth option to the server
            and client programs is no longer supported and using it
            produces an error.
          
            The secure_auth system
            variable permits only a value of 1; a value of 0 is no
            longer permitted.
          
            For the old_passwords
            system variable, a value of 1 (produce pre-4.1 hashes) is no
            longer permitted.
          
            The OLD_PASSWORD() function has been
            removed.
          
            The mysqladmin
            old-password command has been removed.
          
(WL #8006)
        MySQL now includes a server-side authentication plugin named
        mysql_no_login for setting up accounts that
        accept no client connections. This plugin enables DBAs to
        implement the following use cases:
      
            Stored program and view objects that perform sensitive or
            adminstrative operations must run with elevated privileges.
            Less-privileged users must be able to execute these objects
            but not be able to directly log in as the account that has
            the privileges. To implement this, create a no-login account
            using mysql_no_login, grant it the
            required privileges, define objects with a
            DEFINER of that account, and include
            SQL SECURITY DEFINER in the definitions.
          
            Access to a proxy account must always be by the usual proxy
            mechanism, never by users logging in directly to the proxy
            account. To implement this, assign
            mysql_no_login as the authentication
            plugin when you create the proxy account.
          
For more information, see No-Login Pluggable Authentication. (WL #7726)
MySQL distributions now attempt to deploy with SSL and RSA capabilities enabled by default.
To make it easier to support encrypted connections, MySQL servers compiled using OpenSSL now can automatically generate SSL and RSA files at startup if they are missing:
            The server automatically generates server-side and
            client-side SSL certificate and key files in the data
            directory if the new
            auto_generate_certs system
            variable is enabled, no SSL options other than
            --ssl are specified, and the
            server-side SSL files are missing from the data directory.
            These files enable encrypted client connections using SSL.
          
            The server automatically generates RSA private/public
            key-pair files in the data directory if the new
            sha256_password_auto_generate_rsa_keys
            system variable is enabled, no RSA options are specified,
            and the RSA files are missing from the data directory. These
            files enable secure password exchange using RSA over
            unencrypted connections for accounts authenticated by the
            sha256_password plugin.
          
        The server-side --ssl option
        value now is enabled by default for all servers. For servers
        compiled using OpenSSL, if --ssl
        is enabled and other SSL options are not given to configure SSL
        explicitly, the server attempts to enable SSL automatically at
        startup:
      
            If the server finds valid SSL files named
            ca.pem,
            server-cert.pem, and
            server-key.pem in the data directory,
            it enables SSL to permit SSL connections by clients. (These
            files need not have been autogenerated; what matters is that
            they have the indicated names and are valid.)
          
If the server does not find valid SSL files in the data directory, it continues executing but does not enable SSL.
        For any SSL and RSA files that the server finds and uses
        automatically, it uses the file names to set the corresponding
        system variables (ssl_ca,
        ssl_cert,
        ssl_key,
        sha256_password_private_key_path,
        sha256_password_public_key_path).
      
For more information, see Configuring MySQL to Use Encrypted Connections, and Creating SSL and RSA Certificates and Keys using MySQL. (WL #7699)
InnoDB: 
        SPATIAL indexes can now be used for
        InnoDB tables. InnoDB
        supports indexing of spatial data types, including use of
        ALTER TABLE ...
        ALGORITHM=INPLACE for online operations (ADD
        SPATIAL INDEX). To support transaction isolation
        properties, InnoDB uses predicate locking. A
        predicate lock locks the minimum bounding rectangle (MBR) used
        for a query so that other transactions cannot insert or modify a
        row that would match the query condition.
      
For more information, see Optimizing Spatial Analysis. and Predicate Locks for Spatial Indexes. (Bug #18674219, WL #6968, WL #6745, WL #6609)
The Open Geospatial Consortium guidelines document the use of open polygons (polygons where the start point is not equal to the end point) but the MySQL GIS implementation did not support them. Now MySQL supports open polygons: An open polygon is converted to a closed one by appending the starting point to the point sequence. Before:
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
+---------------------------------------------------------------+
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
+---------------------------------------------------------------+
| NULL                                                          |
+---------------------------------------------------------------+
After:
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
+---------------------------------------------------------------+
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
+---------------------------------------------------------------+
| POLYGON((10 10,20 10,20 20,10 20,10 10))                      |
+---------------------------------------------------------------+
(Bug #17168699)
        GeometryCollection() returned
        NULL if the argument contained nonsupported
        geometries. Now
        GeometryCollection() returns all
        the proper geometries contained in the argument even if a
        nonsupported geometry is present.
       (Bug #17168643)
This MySQL release makes increased use of the Boost.Geometry library to provide better reliability and increased functionality for spatial functions. As a result, several previously unimplemented functions have been implemented, and several previously existing functions now accept a wider range of geometry argument types (or argument type combinations for functions that take multiple geometries):
            These previously unimplemented spatial operator functions
            are now available:
            ST_ConvexHull,
            ST_Difference(),
            ST_Intersection(),
            ST_SymDifference(), and
            ST_Union().
          
            These previously existing functions are more robust and
            return non-NULL values for more geometry
            argument types: ST_Area(),
            ST_Centroid(),
            ST_Contains(),
            ST_Crosses(),
            ST_Disjoint(),
            ST_Distance(),
            ST_Envelope(),
            ST_Equals(),
            ST_Intersects(),
            ST_Overlaps(),
            ST_Touches(), and
            ST_Within(). These functions
            also exist as non-ST_ synomyms; for
            example, ST_Area() and
            Area() are synonyms.
          
(WL #7220, WL #7221, WL #7236)
        MySQL now includes functions for converting between GeoJSON
        documents and spatial values:
        ST_AsGeoJSON() and
        ST_GeomFromGeoJSON(). For more
        information, see Spatial GeoJSON Functions.
       (WL #7444)
MySQL now includes functions that enable manipulation of geohash values, which provides applications the capabilities of importing and exporting geohash data, and of indexing and searching geohash values:
            ST_GeoHash() returns a
            geohash string given a return value length and either
            longitude and latitude values or a POINT
            value.
          
            ST_LongFromGeoHash() and
            ST_LatFromGeoHash() return
            the longitude or latitude value, respectively, given a
            geohash string argument.
          
            ST_PointFromGeoHash()
            produces a POINT value from a geohash
            string argument.
          
(WL #7928)
Incompatible Change: These SQL mode changes were made:
            Strict SQL mode for transactional storage engines
            (STRICT_TRANS_TABLES) is
            now enabled by default.
          
            Implementation of the
            ONLY_FULL_GROUP_BY SQL
            mode has been made more sophisticated, to no longer reject
            deterministic queries that previously were rejected.
          
                MySQL now recognizes when a nonaggregated selected
                column is functionally dependent on (uniquely determined
                by) GROUP BY columns.
              
                MySQL has an extension to standard SQL that permits
                references in the HAVING clause to
                aliased expressions in the select list. Previously,
                enabling
                ONLY_FULL_GROUP_BY
                disables this extension, thus requiring the
                HAVING clause to be written using
                unaliased expressions. This restriction has been lifted
                so that the HAVING clause can refer
                to aliases regardless of whether
                ONLY_FULL_GROUP_BY is
                enabled.
              
            In consequence,
            ONLY_FULL_GROUP_BY is now
            enabled by default, to prohibit nondeterministic queries
            containing expressions not guaranteed to be uniquely
            determined within a group.
          
            The changes to the default SQL mode result in a default
            sql_mode system variable
            value with these modes enabled:
            ONLY_FULL_GROUP_BY,
            STRICT_TRANS_TABLES,
            NO_ENGINE_SUBSTITUTION.
          
            The ONLY_FULL_GROUP_BY
            mode is now included in the modes comprised by the
            ANSI SQL mode.
          
            A new function, ANY_VALUE(), is available
            that can be used to force MySQL to accept queries that it
            thinks should be rejected with
            ONLY_FULL_GROUP_BY
            enabled. The function return value and type are the same as
            the return value and type of its argument, but the function
            result is not checked for the
            ONLY_FULL_GROUP_BY SQL
            mode.
          
        If you find that having
        ONLY_FULL_GROUP_BY enabled
        causes queries for existing applications to be rejected, either
        of these actions should restore operation:
      
            If it is possible to modify an offending query, do so,
            either so that nondeterministic nonaggregated columns are
            functionally dependent on GROUP BY
            columns, or by referring to nonaggregated columns using
            ANY_VALUE().
          
            If it is not possible to modify an offending query (for
            example, if it is generated by a third-party application),
            set the sql_mode system variable at
            server startup to not enable
            ONLY_FULL_GROUP_BY.
          
        For more information about SQL modes and GROUP
        BY queries, see Server SQL Modes, and
        MySQL Handling of GROUP BY.
       (Bug #18486310, WL #2489, WL #7764)
Incompatible Change: 
        The GET_LOCK() function has been
        reimplemented using the metadata locking (MDL) subsystem and its
        capabilities have been extended:
      
            Previously, GET_LOCK()
            permitted acquisition of only one named lock at a time, and
            a second GET_LOCK() call
            released any existing lock. Now
            GET_LOCK() permits
            acquisition of more than one simultaneous named lock and
            does not release existing locks.
          
            Applications that rely on the behavior of
            GET_LOCK() releasing any
            previous lock must be modified for the new behavior.
          
            The capability of acquiring multiple locks introduces the
            possibility of deadlock among clients. The MDL subsystem
            detects deadlock and returns an
            ER_USER_LOCK_DEADLOCK error
            when this occurs.
          
The MDL subsystem imposes a limit of 64 characters on lock names, so this limit now also applies to named locks. Previously, no length limit was enforced.
            Locks acquired with
            GET_LOCK() now appear in the
            metadata_locks Performance
            Schema table. The OBJECT_TYPE column says
            USER LEVEL LOCK and the
            OBJECT_NAME column indicates the lock
            name.
          
            A new function,
            RELEASE_ALL_LOCKS() permits
            release of all acquired named locks at once.
          
For more information, see Locking Functions. (WL #1159)
Incompatible Change: Previously, mysql_upgrade performed an upgrade by invoking the mysql and mysqlcheck clients. mysql_upgrade has been reimplemented to generate the required SQL statements itself and execute them by communicating directly with server.
        In consequence of this change, mysql_upgrade
        now supports the
        --bind-address option
        enabling the network interface for connecting to the server to
        be chosen. It also supports
        --net-buffer-length and
        --max-allowed-packet
        options enabling the initial and maximum communication packet
        size to be specified.
      
        Also in consequence of this change,
        mysql_upgrade no longer supports the
        --tmpdir option. This option specified the
        location of temporary files used to supply input to
        mysql, but it no longer has any purpose
        because mysql_upgrade no longer invokes
        mysql. Any upgrade scripts that invoke
        mysql_upgrade and use
        --tmpdir must be modified to remove that
        option.
       (WL #7308)
InnoDB: 
        For optimal shutdown and recovery performance, shutdown and
        recovery phases are now supported by the multithreaded page
        cleaner feature
        (innodb_page_cleaners) that was
        introduced in MySQL 5.7.4.
       (Bug #18805275)
InnoDB: 
        Work was done to introduce the notion of attachable transactions
        in InnoDB (for AutoCommit / ReadOnly /
        ReadCommitted / NonLocking transactions). This is used to read
        from InnoDB Data Dictionary tables. Along
        with this, attachable transactions were exposed to the server.
        Data Dictionary access code will use them to read Data
        Dictionary data.
       (WL #7828, WL #8003)
InnoDB: 
        You can now truncate undo logs that reside in undo tablespaces.
        This feature is enabled using the
        innodb_undo_log_truncate
        configuration option. For more information, see
        Truncating Undo Tablespaces.
       (WL #6965)
InnoDB: 
        InnoDB memory allocations now are
        instrumented for the
        Performance Schema and
        will appear in the
        memory
        summary tables.
       (WL #7777)
InnoDB: 
        Instead of inserting one index record at a time,
        InnoDB now performs a bulk load when creating
        or rebuilding indexes. This method of index creation is also
        known as a sorted index build. This enhancement, which improves
        the efficiency of index creation, also applies to full-text
        indexes. It is not supported with spatial indexes.
      
        A new global configuration option,
        innodb_fill_factor, defines the
        percentage of space on each page that is filled with data during
        a sorted index build, with the remaining space reserved for
        future index growth. For more information, see
        Sorted Index Builds.
       (WL #7277)
InnoDB: 
        The FIL_PAGE_FLUSH_LSN field, written to the
        first page of each InnoDB system tablespace
        file and to InnoDB undo tablespace files, is
        now only written to the first file of the
        InnoDB system tablespace (page number 0:0).
      
        As a result of this patch, if you have a multiple-file system
        tablespace and decide to downgrade from MySQL 5.7 to MySQL 5.6,
        you may encounter an invalid message on MySQL 5.6 startup
        stating that the log sequence numbers
        x and y in
        ibdata files do not match the log sequence number
        y in the ib_logfiles. If
        you encounter this message, restart MySQL 5.6 to ensure that
        startup has run properly. The invalid message should no longer
        appear.
       (WL #7990)
InnoDB: 
        The innodb_buffer_pool_size
        parameter is now dynamic, allowing you to resize the buffer pool
        without restarting the server. The resizing operation, which
        involves moving pages to a new location in memory, is performed
        chunks. Chunk size is configurable using the new
        innodb_buffer_pool_chunk_size
        configuration option. You can monitor resizing progress using
        the new
        Innodb_buffer_pool_resize_status
        status variable. For more information, see
        Configuring InnoDB Buffer Pool Size Online.
      
See Configuring InnoDB Buffer Pool Size Online for more information. (WL #6117)
Replication: 
        When replicating from a master running a version earlier than
        MySQL 5.6.0 to a slave running MySQL 5.6.0 or later, the slave
        requires the master_uuid value, which is the
        server_uuid value from the
        master. The master_uuid value is unsupported
        on the older master, and in such a replication situation could
        become invalid on the newer slave. A check for empty
        master_uuid now ensures that the slave uses
        an empty value for master_uuid.
       (Bug #18338203)
Replication: 
        Retrying of transactions is now supported when multithreading is
        enabled on a slave. In previous versions,
        slave_transaction_retries was
        treated as equal to 0 when using multithreaded slaves.
       (Bug #16390504, Bug #68465, WL #6964)
Replication: 
        Global transaction identifiers (GTIDs) are now logged in a MySQL
        system table whenever they are enabled on the server, which
        lifts a previous requirement to use binary logging when
        replicating with GTIDs. If binary logging is disabled, the
        server stores the GTID for each transaction in the
        mysql.gtid_executed table as the transaction
        is executed. If binary logging is enabled, then, whenever the
        binary log is rotated or the server is shut down, the server
        also writes into the new binary log the GTIDs for all
        transactions from the previous binary log.
      
        Because the mysql.gtid_executed table can
        become filled with many rows with single-transaction GTIDs
        having the same originating server and sequential transaction
        IDs, the server compresses this table periodically whenever
        GTIDs are enabled. You can control the frequency with which the
        table is compressed by setting the
        executed_gtids_compression_period system
        variable. This variable's default value is 1000, which means
        that compression of the table is applied following each 1000
        transactions. You can set the
        executed_gtids_compression_period to 0 to
        disable the compression altogether, but you should be aware that
        doing this may cause the space required by this table to
        increase significantly. (See
        mysql.gtid_executed Table Compression.)
      
        Compression of the mysql.gtid_executed table is performed by a
        dedicated thread. You can obtain information about the state of
        this thread in the threads
        Performance Schema table.
       (Bug #14730192, WL #6559)
Replication: 
        The system variable
        simplified_binlog_gtid_recovery can be used
        to change the way binary log files are searched for previous
        GTIDs during recovery, speeding up the process when a large
        number of binary log files exist.
       (Bug #69097, Bug #16741603, Bug #74071, Bug #19686914)
Replication: 
        The system variable
        binlogging_impossible_mode controls what
        happens if the server cannot write to the binary log, for
        example, due to a file error. For backward compatibility, the
        default for binlogging_impossible_mode is
        IGNORE_ERROR, meaning the server logs the
        error, halts logging, and continues updates to the database.
        Setting this variable to ABORT_SERVER makes
        the server halt logging and shut down if it cannot write to the
        binary log.
       (Bug #51014, Bug #11758766)
Replication: 
        To make monitoring of a replication setup easier, various
        replication related variables have been moved to the
        performance_schema tables. This is
        particularly helpful for monitoring multi-source replication.
       (WL #7817)
Replication: 
        The new SQL function
        WAIT_FOR_EXECUTED_GTID_SET()
        makes the current syncing option for the slave with master
        independent of the slave threads and improves the return value.
       (WL #7796)
Replication: 
        The new options
        binlog_group_commit_sync_delay
        and
        binlog_group_commit_sync_no_delay_count
        provide a way to configure the synchronization of the binary
        log. This enables more transactions to be synchronized together
        to disk at once, reducing the overall time to commit a group of
        transactions because the larger groups require fewer time units
        per group.
       (WL #7742)
Replication: 
        Multithreaded slaves can use the new
        slave_preserve_commit_order
        variable to ensure that the order which transactions were
        committed on the master is preserved on the slave. This prevents
        the slave from entering a state that the master was not in and
        is well suited to using multithreaded slaves for replication
        read scale-out.
       (WL #6813)
        New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support
        that was introduced with 5.6.17 now comes with the
        platform-specific packaging source placed under the
        packaging directory, in the
        deb-precise,
        deb-wheezy, and
        deb-trusty directories.
       (Bug #19020385)
CMake support was updated to handle CMake version 3. (Bug #19001781)
        The rwlock used for the SAFE_HASH
        implementation is now instrumented for the Performance Schema.
        The instrument name is
        wait/synch/rwlock/mysys/SAFE_HASH::lock.
       (Bug #18991366)
The (undocumented) binary-configure.sh script has been removed from MySQL distributions. (Bug #18694238)
        RHEL 4 is not supported for 5.7, so the
        support-files/RHEL4-SElinux file was
        removed.
       (Bug #18651087)
        The (undocumented) FEATURE_SET
        CMake option was removed.
       (Bug #18521389)
        Unused private fields reported by Clang's
        -Wunused-private-field compiler warning option
        were removed.
       (Bug #18489724)
        thr_alarm.h and
        thr_alarm.c were removed because they
        contain dead code almost exclusively. The remaining live code
        was moved to mysqld.cc.
        my_alarm.h and
        my_alarm.c were also removed, and the code
        from them that is actually used was moved to
        my_lock.c.
       (Bug #18411456)
CMake support was updated to handle the new directory layout for Sun C++ 5.13. (Bug #73034, Bug #19010286)
The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
        mysqld help text for
        --general_log was clarified. Thanks to Andrew
        Gaul for the patch.
       (Bug #71463, Bug #18127243)
        The fill_help_tables.sql file that is used
        to load server-side help table content now contains the
        following statement to suppress binary logging and prevent table
        contents from replicating to slaves:
      
SET sql_log_bin=0;
Because help table content is specific to the a particular server version, this prevents loading incorrect content into the slaves, which do not necessarily run the same version of MySQL as the master. (Bug #69564, Bug #17015822)
        The empty string provided for numeric or enumeration options
        (for example, --port="") produced inconsistent
        or confusing behavior. Such empty option values now are rejected
        with an error.
       (Bug #68055, Bug #16102788)
        The mysqladmin flush-logs command now permits
        optional log types to be given, to specify which logs to flush.
        Following the flush-logs command, you can
        provide a space-separated list of one or more of the following
        log types: binary, engine,
        error, general,
        relay, slow. These
        correspond to the log types that can be specified for the
        FLUSH LOGS SQL statement. Thanks
        to Daniël van Eeden for the patch.
       (Bug #60878, Bug #12368203)
        A new status variable,
        Max_used_connections_time,
        indicates the time at which
        Max_used_connections reached
        its current value. Thanks to Jordi Prats for the patch.
       (Bug #59738, Bug #11766596)
        Previously, on Unix and Unix-like systems, MySQL support for
        sending the server error log to syslog was
        implemented by having mysqld_safe capture
        server error output and pass it to syslog.
        The server now includes native syslog
        support, which has been extended to include Windows. Server
        error logging to syslog, Event Log, or a
        file, should be controlled using mysqld
        options. Doing so using mysqld_safe options
        is now deprecated. For more information about sending server
        error output to syslog, see
        The Error Log.
      
        In addition, system log output control is distinct from sending
        error output to a file or the console, on all platforms.
        Previously, this was true only for Windows. On Unix and
        Unix-like systems, error output now can be directed to a file or
        the console in addition to or instead of the system log as
        desired. This is true both for mysqld and
        mysqld_safe. Previously,
        mysqld_safe ignored its
        --syslog option with a
        warning if --log-error was
        also given.
       (Bug #55370, Bug #11762739, WL #7793, WL #8053)
If connection IDs went beyond the 32-bit limit and started over at 1, the server now ensures that IDs still in use will not be reissued. (Bug #44167, Bug #11752851)
        Internally, spatial data types such as
        Geometry are represented as
        BLOB values, so when invoked with the
        --hex-blob option,
        mysqldump now displays spatial values in hex.
       (Bug #43544, Bug #11752369)
        Scalability for InnoDB tables was improved by
        avoiding THR_LOCK locks. As a result of this
        change, DML statements for InnoDB tables that
        previously waited for a THR_LOCK lock will
        wait for a metadata lock:
      
            Explicitly or implicitly started transactions that update
            any table (transactional or nontransactional) will block and
            be blocked by LOCK TABLES ... READ for
            that table. This is similar to how LOCK TABLES ...
            WRITE works.
          
            Tables that are implicitly locked by LOCK
            TABLES now will be locked using metadata locks
            rather than THR_LOCK locks (for
            InnoDB tables), and locked using metadata
            locks in addition to THR_LOCK locks (for
            all other storage engines). Implicit locks occur for
            underlying tables of a locked view, tables used by triggers
            for a locked table, or tables used by stored programs called
            from such views and triggers.
          
            Multiple-table updates now will block and be blocked by
            concurrent LOCK TABLES ... READ
            statements on any table in the update, even if the table is
            used only for reading.
          
            HANDLER ... READ for any storage engine
            will block and be blocked by a concurrent LOCK
            TABLES ... WRITE, but now using a metadata lock
            rather than a THR_LOCK lock.
          
        The preceding changes are visible several ways. For example,
        when a DML statement such as
        INSERT INTO t1
        in one session is blocked by
        LOCK TABLES t1
        READ in another session:
      
            In the Performance Schema, THR_LOCK
            acquisitions and waits will be registered in the
            metadata_locks table and for
            wait/lock/metadata/sql/mdl events rather
            than registered in the
            table_handles table and for
            wait/lock/table/sql/handler events.
          
            In the process list (SHOW
            PROCESSLIST or
            INFORMATION_SCHEMA.PROCESSLIST),
            the state value will be Waiting for table metadata
            lock rather than Waiting for table level
            lock.
          
            The Table_locks_immediate
            and Table_locks_waited
            status variables will no longer be incremented.
          
Issues that went away as a result of these locking changes:
            For debug builds, concurrent execution of LOCK
            TABLES ... READ and a DML statement affecting the
            same InnoDB table might lead to
            Found lock of type 6 that is write and read
            locked warnings in the error log.
          
            Execution of DDL statements under LOCK
            TABLES might have led to deadlock if 1) this
            LOCK TABLES statement, in addition to the
            table to be changed by DDL, also had some tables read-locked
            or locked implicitly (for example, through triggers) and 2)
            there was some concurrent DML which was blocked on a
            table-level lock held by LOCK TABLES and
            3) there was a concurrent PREPARE (or
            corresponding connector API call) which prepared a statement
            using tables to be affected by the first DDL and some other
            table which was affected by another DDL statement which had
            to wait for the DML statement.
          
(Bug #42147, Bug #11751331, WL #6671)
        The mysql client now indicates whether
        USE statements produced warnings.
       (Bug #29965, Bug #11746951)
In the MySQL client/server protocol, EOF and OK packets serve the same purpose, to mark the end of a query execution result. Due to recent changes in the OK packet (such as session state tracking), and to avoid repeating the changes in the EOF packet, the EOF packet is now deprecated. (WL #7766)
        The server-side help tables and time zone tables in the
        mysql system database now are
        InnoDB (transactional) tables. Previously,
        these were MyISAM (nontransactional) tables.
        The affected tables are:
      
help_category help_keyword help_relation help_topic time_zone time_zone_leap_second time_zone_name time_zone_transition time_zone_transition_type
        If you upgrade to this MySQL release from an earlier version,
        you must run mysql_upgrade (and restart the
        server) to incorporate these changes into the
        mysql database.
      
        START TRANSACTION and
        COMMIT statements have been added to the
        output from mysql_tzinfo_to_sql used to
        populate the time zone tables, to ensure that reload operations
        are permanent.
       (WL #7159)
MySQL Server now supports an “offline mode” with these characteristics:
            Connected client users who do not have the
            SUPER privilege are
            disconnected on the next request, with an appropriate error.
            Disconnection includes terminating running statements and
            releasing locks. Such clients also cannot initiate new
            connections, and receive an appropriate error.
          
            Connected client users who have the
            SUPER privilege are not
            disconnected, and can initiate new connections to manage the
            server.
          
Replication slave threads are permitted to keep applying data to the server.
        Only users who have the SUPER
        privilege can control offline mode. To put a server in offline
        mode, change the value of the new
        offline_mode system variable
        from OFF to ON. To resume
        normal operations, change
        offline_mode from
        ON to OFF. In offline
        mode, clients that are refused access receive an
        ER_SERVER_OFFLINE_MODE error.
       (WL #3836)
        ALTER TABLE ...
        EXCHANGE PARTITION syntax now includes an optional
        {WITH|WITHOUT} VALIDATION clause. When
        WITHOUT VALIDATION is specified,
        ALTER TABLE ...
        EXCHANGE PARTITION does not perform row-by-row
        validation when exchanging a populated table with the partition,
        permitting database administrators to assume responsibility for
        ensuring that rows are within the boundaries of the partition
        definition. WITH VALIDATION is the default
        behaviour and need not be specified explicitly. For more
        information, see
        Exchanging Partitions and Subpartitions with Tables.
       (WL #5630)
        mysqlslap now has a
        --sql-mode option that enables
        the SQL mode to be set for the client session.
       (WL #7764)
        It is now possible to specify the storage engine the server uses
        for on-disk internal temporary tables (see
        Internal Temporary Table Use in MySQL), by setting the new
        internal_tmp_disk_storage_engine
        system variable. Permitted values are MYISAM
        (the default) and INNODB.
      
        In consequence of this change, the server is no longer prevented
        from using an in-memory temporary table for queries containing a
        string column in a GROUP BY or
        DISTINCT clause larger than 512 bytes for
        binary strings or 512 characters for nonbinary strings.
       (WL #6711)
The custom rwlock implementation for Windows was replaced with standard Windows API calls. As a result of this change, Windows binaries require Windows 7 / Windows Server 2008 R2 or newer. In particular, Windows binaries no longer work on Windows Vista or Windows Server 2008 (plain, not R2). (WL #7914)
The Boost.Geometry library now is required to build MySQL. Two new CMake options enable control over the library source location, and whether to download it automatically:
            -DWITH_BOOST=
            specifies the Boost library directory location. It is also
            possible to specify the Boost location by setting the
            path_nameBOOST_ROOT or
            WITH_BOOST environment variable.
          
            -DDOWNLOAD_BOOST=
            specifies whether to download the Boost source if it is not
            present in the specified location. The default is
            boolOFF.
          
        For example, if you normally build MySQL placing the object
        output in the bld subdirectory of your
        MySQL source tree, you can build with Boost like this:
      
mkdir bld cd bld cmake .. -DDOWNLOAD_BOOST=ON -DWITH_BOOST=$HOME/my_boost
        This causes Boost to be downloaded into the
        my_boost directory under your home
        directory. If the required Boost version is already there, no
        download is done. If the required Boost version changes, the
        newer version is downloaded.
      
If Boost is already installed locally and your compiler finds the Boost header files on its own, it may not be necessary to specify the preceding CMake options. However, if the version of Boost required by MySQL changes and the locally installed version has not been upgraded, you may have build problems. Using the CMake options should give you a successful build.
Important Change; Partitioning: 
        In an ALTER TABLE statement, the
        server accepted REBUILD with the name of a
        subpartition as valid syntax even though the
        REBUILD keyword in this case did nothing. Now
        REBUILD is rejected in such cases, and causes
        the statement to fail with an error.
       (Bug #19075411, Bug #73130)
References: This issue is a regression of: Bug #14028340, Bug #65184.
Important Change; Replication: 
        A DROP TABLE statement may be
        divided into multiple statements before it is sent to the binary
        log if it contains regular (not temporary) tables and temporary
        tables, or if it contains temporary tables using both
        transactional and non-transactional storage engines. Now, when
        using GTIDs, DROP TABLE statements affecting
        these combinations of tables are no longer allowed unless the
        value of the gtid_next system
        variable is AUTOMATIC. This is because, with
        GTIDs enabled on the server, issuing a DROP
        TABLE in the cases just described while having only
        one GTID associated with each statement (the SQL thread does
        this following
        SET
        gtid_next=')
        causes problems when there are not enough GTIDs for assignment
        to all the resulting statements following the division of the
        original uuid:number'DROP TABLE.
      
        A DROP TABLE statement might be split due to
        the behavior of the statement with respect to the current
        transaction varying, depending on table characteristics, as
        follows:
      
            DROP TABLE of a regular (not temporary)
            table is committed immediately
          
            DROP TABLE of a temporary table using a
            transactional storage engine is committed with the current
            transaction (following
            COMMIT)
          
            DROP TABLE of a temporary table that uses
            a nontransactional storage engine is committed immediately
          
        Naming all three of these types of tables in a single
        DROP TABLE statement causes the MySQL server
        to divide the original statement into three separate
        DROP TABLE statements in the binary log. If
        GTIDs are enabled but the value of gtid_next
        is not AUTOMATIC, issuing a DROP
        TABLE statement that mixes any of the table types
        described previously causes the server to have an insufficient
        number of GTIDs to write with all of the resulting statements
        into the binary log. In addition,
        DROP TABLE IF
        EXISTS is always written in the binary log for all
        tables specified in the statement, even if some or all of the
        tables do not exist.
      
        Because temporary tables are handled differently by
        DROP TABLE depending on whether they use a
        transactional or nontransactional storage engine, any tables
        named by a DROP TEMPORARY TABLE statement
        that do not exist are assumed to be transactional. This means
        that, if a DROP TEMPORARY TABLE with two
        nontransactional temporary tables is issued on the master, it
        would writes only one DROP TABLE statement
        naming both tables. If one of the temporary tables no longer
        exists on the slave, then, when the SQL thread executes the
        statement, it tries to divide it into multiple statements due to
        it affecting a nontransactional (but existing) temporary table
        and a nonexistent transactional temporary table; this leads to
        problems because the SQL thread has only one GTID for the
        original DROP TABLE statement but must write
        two DROP TABLE statements in the binary log.
      
        In addition, when the slave dropped temporary tables after
        detecting that the master had restarted, it logged one
        DROP TABLE statement per pseudo-thread and
        per database, but combined temporary tables using transactional
        and nontransactional storage engines in a single DROP
        TABLE statement.
      
        Now, we throw an error in the client session if
        gtid_next is set to a
        uuid:number
        value and a DROP TABLE statement is issued
        mixing any of the table types described previously.
      
In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.
The slave now also handles dropping of temporary tables correctly in the event of the restart by the master. (Bug #17620053)
Important Change; Replication: 
        The maximum length that can be used for the password in a
        CHANGE MASTER TO statement is 32
        characters. Previously, when a longer password was employed, it
        was accepted, but any excess length was silently truncated by
        the server. Following this fix, when the password's length
        exceeds 32 characters, CHANGE MASTER TO fails
        with an error.
       (Bug #11752299, Bug #43439)
Performance; Replication: 
        When processing the dump thread, a semisynchronous replication
        master checked whether or not the dump thread came from a
        semisynchronous slave by checking the value of
        rpl_semi_sync_slave_enabled,
        but did so for every operation performed on this thread, which
        had significant negative impact on performance. Now this check
        is made only once, when the dump thread is started, which should
        noticeably improve the performance of semisynchronous
        replication in most cases.
       (Bug #17932935)
InnoDB; Partitioning: 
        Large numbers of partitioned InnoDB
        tables could consume much more memory when used in MySQL 5.6 or
        5.7 than the memory used by the same tables used in previous
        releases of the MySQL Server.
       (Bug #17780517, Bug #70641)
References: This issue is a regression of: Bug #11764622, Bug #57480.
InnoDB; Linux: 
        The TTASFutexMutex, the mutex implementation
        that uses the Linux futex, failed to request
        m_lock_word alignment.
       (Bug #19525395, Bug #73760)
InnoDB: 
        If a crash occurs after a drop index action during a
        TRUNCATE TABLE operation, the
        root page could be left in a free state. On crash recovery, an
        LSN check failed to check free
        pages when attempting to pin the root page, resulting in an
        assertion.
       (Bug #19520482)
InnoDB: 
        Replaced a goto statement with an
        if statement in the
        fil_mutex_enter_and_prepare_for_io function
        in fil0fil.cc.
       (Bug #19488149)
InnoDB: 
        An INSERT operation on a table
        with spatial data columns raised an assertion.
       (Bug #19474851)
InnoDB: 
        Removed unused code related to binary log information stored in
        the InnoDB trx_sys page.
       (Bug #19471743)
InnoDB: 
        An ALTER TABLE ...
        ADD FOREIGN KEY operation could cause a serious error.
       (Bug #19471516, Bug #73650)
InnoDB: 
        Reduced mem_heap_zalloc calls in
        upd_create. Only a single call is necessary
        to allocate memory for upd_t.
       (Bug #19297656, Bug #73272)
InnoDB: 
        In debug builds, an INSERT
        operation affecting compressed tables would raise a sync-related
        assertion.
       (Bug #19295893)
InnoDB: 
        An ALTER TABLE operation raised
        an fk_tables.empty() assertion. After calling
        dict_load_foreigns(), all associated tables
        that are linked by a foreign key should be loaded to ensure that
        foreign keys are cached.
       (Bug #19267051)
References: This issue is a regression of: Bug #16244691.
InnoDB: A transaction returned from the transaction pool was not in a clean state. (Bug #19244969)
InnoDB: 
        An MLOG_CHECKPOINT marker was incorrectly
        omitted when performing a log checkpoint.
       (Bug #19233510, Bug #73304)
InnoDB: 
        On crash recovery, InnoDB would call
        exit() when encountering a corruption or
        inconsistency. Some of the exit() calls have
        been removed to allow InnoDB to shut down
        properly.
       (Bug #19229231, Bug #73300)
InnoDB: 
        When multiple
        daemon_memcached_option options
        are defined, the
        INFORMATION_SCHEMA.GLOBAL_VARIABLES
        table and SHOW VARIABLES
        statement should only display the first
        daemon_memcached_option option
        that is defined in the command line string or in the MySQL
        configuration file.
       (Bug #19204759, Bug #73287)
InnoDB: 
        Running SHOW ENGINE INNODB STATUS repeatedly
        under performance testing conditions could result in a serious
        error.
       (Bug #19196052)
InnoDB: 
        Removed unused one_flush variable from
        storage/innobase/include/log0log.h.
       (Bug #19192364, Bug #73269)
InnoDB: 
        Retrieval of multiple values with a single
        get command would return incorrect results
        instead of an error message. The InnoDB
        memcached plugin does not currently support
        retrieval of multiple values with a single
        get command.
       (Bug #19172212, Bug #72453)
InnoDB: Attempting to perform operations on a timed out key would cause the memcached daemon to crash and restart. (Bug #19172013, Bug #72586)
InnoDB: 
        An ALTER TABLE operation that
        does not perform a sort on the clustered index could result in a
        duplicate record.
       (Bug #19163915)
References: See also: Bug #17657223.
InnoDB: Improved error handling, diagnostics, and test coverage related to crash recovery error handling. (Bug #19145637, Bug #73179)
InnoDB: 
        Improved error handling for calls to
        handler::records().
       (Bug #19142753, WL #6742)
References: This issue is a regression of: Bug #16802288.
InnoDB: 
        With a transaction isolation level less than or equal to
        READ COMMITTED, gap locks were not taken when
        scanning a unique secondary index to check for duplicates. As a
        result, duplicate check logic failed allowing duplicate key
        values in the unique secondary index.
       (Bug #19140907)
References: This issue is a regression of: Bug #16133801.
InnoDB: 
        A race condition that occurred when dynamically disabling
        innodb_adaptive_hash_index
        caused the purge thread to assert.
       (Bug #19069698, WL #6117, WL #6578)
InnoDB: 
        The INNODB_PAGE_ATOMIC_REF_COUNT
        CMake option is removed in MySQL 5.7.5. This
        option was enabled by default but could be disabled for systems
        that do not support atomic operations. As of MySQL 5.7.5,
        support for atomic operations is required to build MySQL, making
        the INNODB_PAGE_ATOMIC_REF_COUNT option
        obsolete.
       (Bug #19061440, WL #7655, WL #7682)
InnoDB: 
        In debug builds, an invalid rw_latch ==
        RW_NO_LATCH assertion would cause the server to halt.
       (Bug #18977128)
InnoDB: Added debug assertions to the adaptive hash index code to check that the tablespace ID in buffer blocks match the index space. (Bug #18965518, Bug #72986)
InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
References: This issue is a regression of: Bug #11830883.
InnoDB: 
        A code comment for the os_event_is_set
        function in storage/innobase/os/os0event.cc
        was incorrect.
       (Bug #18940008, Bug #72919)
InnoDB: 
        A latching order violation would occur while inserting
        BLOB data.
       (Bug #18883885)
InnoDB: 
        For PowerPC, InnoDB now uses special PowerPC
        instructions for setting priority of hardware threads in
        InnoDB mutex spin loops. Thanks to Stewart
        Smith for the contribution.
       (Bug #18842925, Bug #72754)
InnoDB: 
        The innodb_memcached_config.sql configuration
        script failed after running the
        mysql_secure_installation script, which
        removes the MySQL test database. The
        innodb_memcached_config.sql script now
        creates the test database if it does not
        exist.
       (Bug #18816381, Bug #72678)
InnoDB: 
        Removed unused function definitions and declarations from the
        InnoDB memcached API.
       (Bug #18815992, Bug #72723)
InnoDB: 
        CACHE_LINE_SIZE for PowerPC was changed from
        64 bytes to 128 bytes.
       (Bug #18814859, Bug #72718)
InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition. (Bug #18806829)
InnoDB: 
        trx_cleanup_at_db_startup failed to reset
        trx->rsegs->m-redo content in debug
        code.
       (Bug #18795594)
InnoDB: 
        On mysqld start, specifying multiple data
        files using the
        innodb_data_file_path option
        would return a Space id in fsp header
        error after data is written to the second file.
       (Bug #18767811)
InnoDB: 
        When storing BLOB data,
        InnoDB failed to reserve the required
        tablespace pages prior to allocating the pages, which raised an
        assertion on INSERT.
       (Bug #18756233)
InnoDB: 
        A failed in-place ALTER TABLE
        operation would leave behind nonunique temporary file names in
        the data dictionary preventing future ALTER
        TABLE operations on the same table due to temporary
        file name conflicts. To avoid this problem, temporary file names
        are made unique by appending a static global number that is
        initialized to a random distributed 32-bit number using
        ut_time() and ut_crc32().
        The number is then incremented atomically for each assigned
        temporary file name. Previously, temporary files were named
        using the format #sql-ibtid, where
        tid is the table ID. Temporary files are now
        named using the format #sql-ibtid-inc,
        where tid is the table ID and
        inc is the incremented number.
       (Bug #18734396, Bug #72594)
InnoDB: 
        A regression introduced by the fix for Bug #11758237 resulted in
        a cursor->index->name ==
        TEMP_INDEX_PREFIX assertion.
       (Bug #18723872)
References: This issue is a regression of: Bug #11758237.
InnoDB: For single item full-text searches, deleted documents were included in inverse document frequency (IDF) calculations. (Bug #18711306, Bug #72548)
InnoDB: 
        The page_create function has been optimized
        to use simpler functions to initialize pages.
       (Bug #18704384)
InnoDB: 
        A DELETE operation on a table with full-text
        search indexes raised an assertion.
       (Bug #18683832)
References: See also: Bug #14639605.
InnoDB: 
        To-be-imported tablespace files
        (FIL_TYPE_IMPORT) were not flushed after
        being converted to normal tablespace files
        (FIL_TYPE_TABLESPACE), resulting in too many
        open files.
       (Bug #18663997)
References: This issue is a regression of: Bug #18236692.
InnoDB: 
        When InnoDB is built as a shared library,
        attempting to load the InnoDB full-text
        search (FTS) INFORMATION_SCHEMA plugin would
        fail with a Can't open shared library
        'ha_innodb.so' error.
       (Bug #18655281, Bug #70178)
InnoDB: 
        When calling the memcached
        flush_all command, InnoDB
        attempts to initialize a connection and a transaction. If the
        transaction is in TRX_STATE_NOT_STARTED
        state, InnoDB failed to set
        CONN_DATA->CRSR_TRX to NULL, resulting in
        a serious error.
       (Bug #18652854)
InnoDB: 
        An INSERT operation on a table
        with BLOB columns raised an
        assertion.
       (Bug #18646430)
References: This issue is a regression of: Bug #16963396.
InnoDB: 
        An INSERT operation on a table with
        GEOMETRY columns raised an assertion in
        rtr_page_split_and_insert().
       (Bug #18644435)
InnoDB: 
        The temporary tablespace file (ibtmp1) was
        held open by the page_cleaner thread and
        could not be removed on startup, resulting in a hang.
       (Bug #18642372)
InnoDB: 
        A regression introduced in MySQL 5.6.5 would cause full-text
        search index tables to be created in the system tablespace
        (space 0) even though
        innodb_file_per_table was
        enabled.
       (Bug #18635485)
InnoDB: 
        After upgrading from 5.6.10 to MySQL versions up to and
        including MySQL 5.6.18, InnoDB would attempt
        to rename obsolete full-text search auxiliary tables on server
        startup, resulting in an assertion failure.
       (Bug #18634201, Bug #72079)
InnoDB: In rare cases, the purge process would attempt to delete a secondary index record that was not marked for deletion, resulting in an inconsistent secondary index. (Bug #18631496)
InnoDB: 
        After running OPTIMIZE TABLE on
        an InnoDB table with a spatial index, running
        a SELECT statement that uses the
        spatial index could result in a crash.
       (Bug #18619945, Bug #72361)
References: This issue is a regression of: Bug #13975225.
InnoDB: 
        On startup, with
        innodb_file_per_table=ON, the
        page cleaner thread would raise a
        srv_get_active_thread_type() == SRV_NONE
        debug assertion when encountering an active master thread.
       (Bug #18598813)
InnoDB: 
        InnoDB would try to merge a b-tree change
        buffer for a dedicated undo tablespace.
       (Bug #18593561)
InnoDB: 
        Included unistd.h in
        innodb.cmake to enable futexes in debug
        builds.
       (Bug #18522549, Bug #72225)
InnoDB: 
        TRUNCATE TABLE would write
        page-level redo logs during the DROP
        TABLE step of a TRUNCATE
        TABLE operation.
       (Bug #18511398)
InnoDB: 
        A COMMIT operation related to full-text
        search resulted in a segmentation fault.
       (Bug #18503734)
InnoDB: 
        srv_active_wake_master_thread() was called
        directly in innobase_commit and
        innobase_prepare, waking up the master thread
        and incrementing srv_activity_count.
        srv_active_wake_master_thread() should only
        be called after committing write transactions, not after
        read-only transactions or rollbacks. This patch also replaces
        some calls to srv_active_wake_master_thread()
        with calls to ib_wake_master_thread().
       (Bug #18477009, Bug #72137)
InnoDB: 
        A DB_LOCK_WAIT during a foreign key check
        caused redundant delete marking, resulting in a failing
        assertion.
       (Bug #18451287)
InnoDB: 
        With UNIV_SYNC_DEBUG enabled, a late call to
        sync_check_enable() would result in an
        m_enabled assertion failure.
       (Bug #18433658)
InnoDB: 
        InnoDB would write to the redo log for an
        IMPORT TABLESPACE operation before the
        tablespace import was complete.
       (Bug #18424134)
InnoDB: 
        The InnoDB memcached
        plugin would call plugin_del without
        acquiring the lock_plugin mutex. This bug fix
        also addresses a race condition in
        ib_cursor_delete_row.
       (Bug #18409840)
InnoDB: 
        The os_event_wait_time_low function would
        sometimes return OS_SYNC_TIME_EXCEEDED before
        the sync time has elapsed.
       (Bug #18386498)
InnoDB: 
        With persistent statistics enabled, SHOW
        TABLE STATUS output and the
        TABLE_ROWS column of
        INFORMATION_SCHEMA.TABLES could report an
        incorrect number of table rows for tables with externally stored
        pages.
       (Bug #18384390)
InnoDB: 
        Running a SELECT on a partitioned table
        caused a memory access violation in memcpy().
       (Bug #18383840)
References: See also: Bug #18167648.
InnoDB: A regression introduced by the fix for Bug#18069105 could result in a table corruption and failing assertions. (Bug #18368345)
References: This issue is a regression of: Bug #18069105.
InnoDB: 
        The data file was not opened prior to calling
        fil_fusionio_enable_atomic_write(), resulting
        in an assertion failure.
       (Bug #18368241)
InnoDB: The fix for Bug#17699331 caused a high rate of read/write lock creation and destruction which resulted in a performance regression. (Bug #18345645, Bug #71708)
References: This issue is a regression of: Bug #17699331.
InnoDB: Code quality improvements for the redo log subsystem. (Bug #18345004)
InnoDB: 
        Added the C++ ostream mechanism for error
        logging.
       (Bug #18320915)
InnoDB: 
        Removed the recv_max_parsed_page_no code
        variable, which was only used in a diagnostic error message.
       (Bug #18312967)
InnoDB: 
        buf_pool->flush_rbt, which is only
        intended to be used for recovery, would be allocated for
        database creation and never freed.
       (Bug #18253089)
InnoDB: 
        Calls to sched_getcpu would cause page
        faults.
       (Bug #18225489)
InnoDB: 
        ib_heap_resize failed to verify that
        new_size is greater than or equal to
        old_size before calling
        memcpy.
       (Bug #18178915)
InnoDB: 
        After crash recovery and with UNIV_DEBUG
        enabled, purge failed with a buf_pool_from_bpage(bpage)
        == buf_pool assertion failure.
       (Bug #18154145)
InnoDB: 
        Assertion code in buf_page_release_latch() in
        buf0buf.ic was too restrictive.
       (Bug #17869571)
InnoDB: 
        For each insert, memset would be called three
        times to allocate memory for system fields. To reduce CPU usage,
        the three memset calls are now combined into
        a single call.
       (Bug #17858679, Bug #71014)
InnoDB: 
        The fix for Bug#16418661 added superfluous
        buf_flush_list() logic to
        InnoDB startup code.
       (Bug #17798076, Bug #70899)
References: This issue is a regression of: Bug #16418661.
InnoDB: 
        A problem renaming temporary tables during an ALTER
        TABLE operation would raise an assertion and print a
        warning to the error log. Temporary table names were not
        sufficiently unique.
       (Bug #17713871)
InnoDB: 
        In-place ALTER TABLE operations
        requiring a table rebuild would sort the clustered index even
        though the primary key order remained unchanged. This behavior
        caused unnecessary temporary table usage and I/O.
       (Bug #17657223)
InnoDB: 
        Under certain circumstances, adaptive hash index latches
        (btr_search_latch) were persistent. With
        atomics-based rw-locks (read-write locks), persistent adaptive
        hash index latches are unnecessary and may block other adaptive
        hash index updates.
       (Bug #17554489, Bug #70216)
InnoDB: 
        A race condition in fts_get_next_doc_id
        resulted in Duplicate FTS_DOC_ID and
        Cannot find index FTS_DOC_ID_INDEX in InnoDB index
        translation table errors.
       (Bug #17447086, Bug #70311)
References: See also: Bug #16469399.
InnoDB: 
        Enabling the InnoDB Table Monitor would
        result in a ib_table->stat_initialized
        assertion failure.
       (Bug #17039528, Bug #69641)
InnoDB: 
        Redo log writes for large, externally stored
        BLOB fields could overwrite the most recent
        checkpoint. The 5.6.20 patch limits the size of redo log
        BLOB writes to 10% of the redo
        log file size. The 5.7.5 patch addresses the bug without
        imposing a limitation. For MySQL 5.5, the bug remains a known
        limitation.
       (Bug #16963396, Bug #19030353, Bug #69477)
InnoDB: 
        The error log message that is printed on
        CREATE TABLE when the number of
        BLOB or
        TEXT fields exceed the row size
        limit did not provide sufficient information. The error message
        now provides the maximum row size, current row size, and the
        field that causes the maximum row size to be exceeded.
       (Bug #16874873, Bug #69336)
InnoDB: 
        An in-place ALTER TABLE operation on a table
        with a broken foreign key constraint could raise an assertion.
       (Bug #16869435)
InnoDB: 
        The lock_number_of_rows_locked function used
        a bit vector to track the number of record locks held by a
        transaction. To optimize reporting, the bit vector was replaced
        by a simple counter.
       (Bug #16479309, Bug #68647)
InnoDB: 
        Inserting a record into an InnoDB table with
        a key that falls between the maximum key of a full page and the
        minimum key of the “next” page could result in
        unnecessary page splits and under-filled pages. If the insert
        point is at the end of a page, InnoDB now
        attempts to insert to the next page before splitting the page.
       (Bug #15923864, Bug #67718)
InnoDB: 
        With
        innodb_max_dirty_pages_pct=0
        buffer pool flushing would not be initiated until the percentage
        of dirty pages reached at least 1%, which would leave up to 1%
        of dirty pages unflushed.
       (Bug #13029450, Bug #62534)
InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently. (Bug #11755438, Bug #47213)
InnoDB: 
        Debug assertion code in file row0ins.cc did
        not account for rw-lock shared-exclusive (sx-lock) mode,
        resulting in an assertion failure.
       (Bug #73534, Bug #19420253)
InnoDB: 
        With foreign_key_checks=0,
        InnoDB permitted an index required by a
        foreign key constraint to be dropped, placing the table into an
        inconsistent and causing the foreign key check that occurs at
        table load to fail. InnoDB now prevents
        dropping an index required by a foreign key constraint, even
        with foreign_key_checks=0. The
        foreign key constraint must be removed before dropping the
        foreign key index.
       (Bug #70260, Bug #17449901)
Partitioning: 
        When the
        index_merge_intersection flag
        (enabled by default) or the
        index_merge_union flag was
        enabled by the setting of the
        optimizer_switch system
        variable, queries returned incorrect results when executed
        against partitoned tables that used the
        MyISAM storage engine, as well as
        partitioned InnoDB tables that
        lacked a primary key.
       (Bug #18167648)
References: See also: Bug #16862316, Bug #17588348, Bug #17648468.
Partitioning: 
        Selecting from a table having multiple columns in its primary
        key and partitioned by LIST
        COLUMNS(, where
        R)R was the last (rightmost) column
        listed in the primary key definition, returned an incorrect
        result.
       (Bug #17909699, Bug #71095)
Replication: 
        Misleading or confusing error messages have been revised, which
        were produced in the following 2 cases when using
        mysqlbinlog with the
        --raw option:
      
            When this option was used together with
            --include-gtids.
          
            When this option was used together with
            --exclude-gtids and
            --read-from-remote-master=BINLOG-DUMP-NON-GTIDS.
          
(Bug #19459836, Bug #73625)
Replication: After the fix for Bug #16861624, killing a multithreaded slave worker which was waiting for a commit lock caused a debug assertion to fail. This fix ensures that such a situation can not occur. (Bug #19311260)
Replication: 
        Temporary errors related to a slave worker thread which was
        retrying a transaction were visible in SHOW
        SLAVE STATUS. This fix ensures that slave worker
        threads do not store temporary errors in the slave status.
       (Bug #19282301)
Replication: 
        A corrupted header length in
        FORMAT_DESCRIPTION_LOG_EVENT could cause the
        server to stop unexpectedly. This was due to
        FORMAT_DESCRIPTION_LOG_EVENT being considered
        invalid if the header length was too short.
       (Bug #19145712)
Replication: Removed an unnecessary write lock that was taken by an internal function while adding a GTID to a GTID set, which should improve the performance of the function and the code dependent on it during such operations. (Bug #18963555, Bug #72977)
Replication: 
        Semisynchronous replication did not work as expected when the
        rpl_semi_sync_master_wait_no_slave
        and
        rpl_semi_sync_master_wait_for_slave_count
        variables were set. The values of the variables were changed,
        but the related internal status was not updated during
        initialization.
       (Bug #18835117, Bug #18466390)
Replication: 
        RESET SLAVE
        ALL did not clear
        IGNORE_SERVER_IDS, although this statement
        should clear any values that are set by
        CHANGE MASTER TO. Now
        RESET SLAVE ALL always empties the list of
        server IDs to ignore, whenever it is executed.
       (Bug #18816897)
Replication: The same internal function had effects which caused three similar problems when resetting or starting slaves. These three issues are listed here:
            RESET SLAVE automatically set
            the heartbeat period
            (Slave_heartbeat_period)
            to its default value.
          
            RESET SLAVE automatically set
            SSL_VERIFY_SERVER_CERT to the default.
          
            When a server was not configured as a slave (that is, when
            no CHANGE MASTER TO statement
            had yet been executed), the subsequent failure of
            START SLAVE was expected but
            had the unintended side effect of resetting the heartbeat
            period to the default.
          
        The function has been rewritten such that code affecting
        heartbeat or SSL certificate usage has been eliminated or moved
        to a more appropriate location, eleminating the side effects
        formerly seen with RESET SLAVE or a failed
        START SLAVE.
      
        As part of this fix, in order to be able to keep heartbeats
        enabled by default when changing the master, if host and port
        are given but the heartbeat period is not specified in a
        CHANGE MASTER TO statement, we force it to
        the default value.
       (Bug #18791604, Bug #18778485, Bug #18777899)
Replication: 
        mysqlbinlog
        --raw did not check for
        errors caused by failed writes, which could result in silent
        corruption of binary logs. Now in such cases it stops with an
        error.
       (Bug #18742916, Bug #72597)
Replication: 
        When committing a transaction, a flag is now used to check
        whether a thread has been created, rather than checking the
        thread itself, which uses more resources, particularly when
        running the server with
        master_info_repository=TABLE.
       (Bug #18684222)
References: See also: Bug #17967378.
Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer. (Bug #18563480)
Replication: 
        Log rotation events could cause
        group_relay_log_pos to be moved forward
        incorrectly within a group. This meant that, when the
        transaction was retried, or if the SQL thread was stopped in the
        middle of a transaction following one or more log rotations
        (such that the transaction or group spanned multiple relay log
        files), part or all of the group was silently skipped.
      
This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multithreaded slave, even in the middle of a group. (Bug #18482854)
Replication: 
        When using GTIDs with MASTER_AUTO_POSITION
        enabled, if an I/O thread was restarted it failed with an
        ER_GTID_NEXT_TYPE_UNDEFINED_GROUP
        error due to a partial transaction not being correctly rolled
        back before resuming the I/O thread. This fix ensures that the
        partial transaction is correctly rolled back.
       (Bug #18472603)
Replication: 
        When using row-based replication, updating or deleting a row on
        the master that did not exist on the slave led to failure of the
        slave when it tried to process the change. This problem occurred
        with InnoDB tables lacking a
        primary key.
       (Bug #18432495, Bug #72085)
Replication: 
        A multithreaded slave now checks that a free worker is available
        to dispatch the next event. In previous versions, a
        multithreaded slave crashes with a worker error if the thread
        coordinator can not find a free worker. The crash was caused
        when the coordinator did not return a free worker, for example
        if the coordinator was aborted at the same time using
        STOP SLAVE.
       (Bug #18363515)
Replication: 
        When replicating from a MySQL 5.5 or earlier master to a MySQL
        5.6 or later slave, the SOURCE_UUID column of
        the slave's
        performance_schema.replication_connection_status
        table contained random data. Now in such cases,
        SOURCE_UUID is left blank.
       (Bug #18338203)
Replication: During relay log initialization, the thread context was used as a flag for the reconstruction of the retrieved GTID set, an operation that does not depend on this parameter. This could be problematic if relay log initialization was called in another context other than the legacy replication scenario; if the invocation was made in a context where the thread context was always present, this prevented the set's reconstruction. The opposite could also happen when the thread context was not present, which cause the initialization to be performed twice.
To avoid such issues, the thread context flag is replaced with a new flag that allows the reconstruction in all contexts but prevents multiple invocations. (Bug #18337036)
Replication: 
        When mysqlbinlog processed multiple binary
        log files into a single output file, this file was not in a
        useful state for point-in-time recovery, when it failed with the
        error, When @@SESSION.GTID_NEXT is set to a GTID, you
        must explicitly set it to a different value after a COMMIT or
        ROLLBACK. Please check GTID_NEXT variable manual page for
        detailed explanation. Current @@SESSION.GTID_NEXT is
        'xyz'. When
        mysqlbinlog processes a binary log containing
        GTIDs, it outputs
        SET
        gtid_next statements, but
        gtid_next is set to undefined whenever a
        commit occurs; this left gtid_next undefined
        when the server had finished processing the output from
        mysqlbinlog. When the next binary log file
        started with one or more anonymous statements or transactions,
        the combination of gtid_next being left undefined at the end of
        the first binary log and the second binary log containing
        anonymous transactions to the error described previously (Error
        1837,
        ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
      
        To fix this issue, now, whenever mysqlbinlog
        encounters this situation, it inserts SET gtid_next =
        AUTOMATIC if required to avoid leaving the previous
        binary log with gtid_next undefined.
      
In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)
Replication: 
        Quotation marks were not always handled correctly by
        LOAD DATA when written into the
        binary log.
       (Bug #18207212, Bug #71603)
Replication: 
        Changing master_info_repository
        between TABLE and FILE
        could produce duplicate values in the
        Replicate_Ignore_Server_Ids column of the
        output from SHOW SLAVE STATUS and
        the Ignored_server_ids column of the
        mysql.slave_master_info table. This could
        arise because the list of IDs stored internally by the server
        was not always sorted before checking for duplicates when
        inserting new values into the list. Now the list of server IDs
        to be ignored is always sorted, prior to performing this check.
       (Bug #18192817, Bug #18593479, Bug #18920203)
Replication: 
        In certain cases, the server mishandled triggers and stored
        procedures that tried to modify other tables when called by
        CREATE
        TABLE ... SELECT. This is now handled correctly as an
        error.
       (Bug #18137535)
Replication: 
        The REPLICATE_WILD_DO_TABLE and
        REPLICATE_WILD_IGNORE_TABLE options for
        CHANGE REPLICATION FILTER could
        be employed with values which contained no period
        (.) character, even though values for these
        options must be in the format
        db_name.tbl_name
Replication: 
        When used on a table employing a transactional storage engine, a
        failed TRUNCATE TABLE was still
        written to the binary log and thus replayed on the slave. This
        could lead to inconsistency when the master retained data that
        was removed on the slave.
      
        Now in such cases TRUNCATE TABLE is logged
        only when it executes successfully.
       (Bug #17942050, Bug #71070)
Replication: 
        Beginning in MySQL 5.6.20, when a user specified
        AUTO_INCREMENT value falls outside of the
        range between the current AUTO_INCREMENT
        value and the sum of the current and number of rows affected
        values it is replicated correctly. In previous versions, an
        error was generated by the slave even if the user specified
        AUTO_INCREMENT value fell outside of the
        range.
       (Bug #17588419, Bug #70583)
Replication: When the I/O thread reconnected to a master using GTIDs and multithreaded slaves while in the middle of a transaction, it failed to abort the transaction, leaving a partial transaction in the relay log, and then retrieving the same transaction again. This occurred when performing a rotation of the relay log. Now when reconnecting, the server checks before rotating the log in such cases, and waits first for any ongoing transaction to complete. (Bug #17326020)
Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server. (Bug #17076131)
Replication: 
        When the binary log was rotated due to receipt of a
        SIGHUP signal, the new binary log did not
        contain the Previous_gtid_event required for
        subsequent processing of that binary log's GTID events. Now when
        SIGHUP is received, steps are taken to insure
        that the server writes the necessary
        Previous_gtid_event to the new log before
        writing any GTID events to the new log.
       (Bug #17026898)
Replication: 
        The CLIENT_REMEMBER_OPTIONS flag for
        compressed slave connections is no longer reset and all options
        are retained. This restores functionality of all options to
        compressed slave connections.
       (Bug #72901, Bug #18923691, Bug #73324, Bug #19244772)
Replication: 
        When using row-based replication, setting a slave's
        slave_rows_search_algorithms
        variable to HASH_SCAN caused an
        ER_KEY_NOT_FOUND error even
        though that record existed in the storage layer. This fix
        ensures that the unique key for each record is correctly
        maintained and such a situation does not occur.
       (Bug #72788, Bug #18860225)
Replication: When using row-based replication, running a long transaction involving a large number of events could trigger an Out of Memory (OOM) error if the slave's table structure was not compatible with the master's table structure. Such an incompatible situation could occur if the table on the slave had been manually changed, or when replicating between different MySQL versions that have different data types. This OOM error was caused because the virtual temporary tables created for the row conversion were not being freed until the end of the transaction, which was a problem when replicating large numbers of events.
Starting with this version, such virtual tables are correctly freed during the conversion process. (Bug #72610, Bug #18770469)
References: See also: Bug #19692387.
Replication: The error messages generated when a duplicate server UUID causes issues during replication have been improved. The slave error now identifies the duplicate server UUID and the master error identifies the zombie thread that has been killed. (Bug #72578, Bug #18731211)
Replication: 
        When an event group was spanned across multiple relay log files,
        a slave could incorrectly identify GTID-header group boundaries.
        This meant that when a transaction was retried, or if the SQL
        thread was stopped in the middle of a transaction after some
        rotates, the Gtid_log_event was being
        silently skipped on the slave, and the transaction was logged
        with the slave's GTID. This problem also impacted on using
        START SLAVE UNTIL MASTER_LOG_POS =
         with GTIDs
        enabled. If log_pos;log_pos was in the middle
        of a transaction, the Gtid_log_event was not
        correctly detected as the beginning of the transaction and
        replication stopped before this event. With this fix, threads
        correctly detect that they are part of a group, and this is used
        to check if a Gtid_log_event is part of a
        transaction.
       (Bug #72313, Bug #18652178, Bug #18306199)
Replication: 
        When gtid_mode=ON, and a
        transaction is filtered out on the slave, the GTID of the
        transaction is still logged on the slave as an
        “empty” transaction (consisting of a GTID followed
        immediately by
        BEGIN and then
        COMMIT). This is necessary to
        prevent the transaction from being retransmitted the next time
        the slave reconnects or is involved in a failover. The current
        fix addresses two issues relating to such “empty”
        transactions:
      
            No empty transaction was generated for
            CREATE
            TEMPORARY TABLE or
            DROP TEMPORARY
            TABLE statements.
          
            If the slave used a database filter
            (--replicate-do-db or
            --replicate-ignore-db
            option), no empty transaction was generated.
          
(Bug #71376, Bug #18095502, Bug #18145032)
Replication: 
        Client applications should be able to set the
        BINLOG_DUMP_NON_BLOCK flag in the initial
        handshake packet (COM_BINLOG_DUMP). Clients
        connecting to a server issuing a
        COM_BINLOG_DUMP with the flag unset do not
        get an EOF when the server has sent the last event in the binary
        log, which causes the connection to block. This flag, which was
        removed in error in MySQL 5.6.5, is now restored in the current
        release.
      
        As part of this fix, a new
        --connection-server-id
        option is added to mysqlbinlog. This option
        can be used by the client to test a MySQL server for the
        presence of this issue.
       (Bug #71178, Bug #18000079)
Replication: 
        On a master that is using semisynchronous replication, where
        rpl_semi_sync_master_wait_no_slave
        is enabled and
        rpl_semi_sync_master_timeout is
        set to long timeout, killing the I/O thread could cause the
        server to hang on shutdown. This fix ensures that if the dump
        thread finds that there no semisynchronous slaves connected to
        the master, the setting of
        rpl_semi_sync_master_wait_no_slave is ignored
        and the shutdown proceeds correctly.
       (Bug #71047, Bug #17879675)
Replication: Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running. (Bug #70391, Bug #17638477)
Replication: When using semisynchronous replication, if the binary log position was changed to a future position on a slave then an assertion error was generated on the master. This fix ensures that in such a situation the future position is correctly acknowledged and an error is instead generated on the slave. (Bug #70327, Bug #17453826)
Replication: 
        Replication of tables that contained temporal type fields (such
        as TIMESTAMP, DATETIME,
        and TIME) from different MySQL versions
        failed due to incompatible TIMESTAMP types.
        The fractional TIMESTAMP format added in
        MySQL 5.6.4 was not being correctly converted. You can now
        replicate a TIMESTAMP in either format
        correctly according to the
        slave_type_conversions
        variable.
       (Bug #70124, Bug #17532932)
Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
            Dump thread reconnects from slave; on master, a new dump
            thread tries to kill zombie dump threads; having acquired
            the thread's LOCK_thd_data, it is about
            to acquire LOCK_log.
          
            Application thread executing show binary logs, having
            acquired LOCK_log and about to acquire
            LOCK_index.
          
            Application thread executing PURGE BINARY
            LOGS; having acquired
            LOCK_index, it is about to acquire
            LOCK_thread_count.
          
            Application thread executing SHOW
            PROCESSLIST (or SELECT * FROM
            INFORMATION_SCHEMA.PROCESSLIST), having acquired
            LOCK_thread_count and about to acquire
            the zombie dump thread's LOCK_thd_data.
          
This leads to the 4 threads deadlocking in the same order which the threads have been listed here.
        This problem arises because there are ordering rules for
        LOCK_log and LOCK_index,
        as well as rules for ordering
        LOCK_thread_count and
        LOCK_thd_data, but there are no rules for
        ordering across these two sets of locks. This was because the
        internal mysqld_list_processes() function
        invoked by SHOW PROCESSLIST acquired
        LOCK_thread_count for the complete lifetime
        of the function as well as acquiring and releasing each thread's
        LOCK_thd_data. Now this function takes a copy
        of the threads from the global thread list and performs its
        traversal on these, and only after releasing
        LOCK_thread_count. During this traversal,
        removal from the global thread list is blocked using
        LOCK_thd_remove such that the copies that
        would otherwise be destroyed by the removal remain valid during
        traversal. The locking order following this fix is shown here:
      
LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count
(Bug #69954, Bug #17283409)
References: See also: Bug #73475, Bug #19364731, Bug #19365180.
Replication: When an SQL thread which was waiting for a commit lock was killed and restarted it caused a transaction to be skipped on slave. This fix ensures that thread positions are correctly persisted and transactions resume at the correct position. (Bug #69873, Bug #17450876)
Microsoft Windows: 
        To help with crash analysis on Windows, more information has
        been added to the core file that is written on
        mysqld abort when the
        core-file option is enabled.
       (Bug #14041454)
With DTrace support enabled, certain other compilation options could cause the build to fail. (Bug #19506247)
yaSSL client code did not validate the encryption size or session ID length, which could cause the client to exit. (Bug #19463277, Bug #19463565)
Before fsync operations, the server reports a wait, but it reported a table-lock wait rather than a sync wait. This is a minor problem, possibly resulting in come incorrect thread pool plugin statistics. (Bug #19428231)
The optimizer could raise an assertion due to incorrectly handling the table map while sorting an internal temporary table. (Bug #19416826)
yaSSL could fail preauthorization if the client supplied inaccurate buffer lengths. (Bug #19370676, Bug #19355577)
Using Multi-Range Read (MRR) for table access could leak Performance Schema instrumented table handles. (Bug #19301539)
        For InnoDB full-text searches, invalid
        multibyte gb10830 characters could cause a
        server exit.
       (Bug #19233075)
Competition between threads could lead to timeout failure trying to rotate the audit log file. (Bug #19184973)
        On Windows, sql_yacc.cc and
        sql_yacc.h were generated twice during the
        build process. This can lead to compilation failure if parallel
        processes are permitted.
       (Bug #19060850, Bug #27470071, Bug #89482)
        Repetitive functions called as arguments to
        ExtractValue() were not always
        handled correctly.
       (Bug #19051306)
        For large sets, EXPORT_SET()
        could produce undefined results or a cause a server exit.
       (Bug #19048609)
        Invalid utf16 data could cause the server to
        become unresponsive.
       (Bug #18937504)
        LPAD() and RPAD() could
        cause a server exit if the pad string argument was not well
        formed.
       (Bug #18935421)
The optimizer could create a zero-length column for a temporary table, causing a server exit. (Bug #18928848)
In debug builds, certain range queries could cause an assertion failure. (Bug #18921626)
        Improper copying of query strings between the
        Prepared_statement and THD
        data structures could result in a server exit.
       (Bug #18920075)
        Performance Schema memory instrumentation did not honor the
        ENABLED flag in the
        setup_instruments table or the
        consumers in the setup_consumers
        table. This has been corrected, with the result that unnecessary
        statistics are not collected and overhead is reduced.
       (Bug #18900309)
        When a SELECT included a derived table in a
        join in its FROM list and the
        SELECT list included
        COUNT(DISTINCT), the
        COUNT() returned 1 even if the underlying
        result set was empty.
       (Bug #18853696)
References: This issue is a regression of: Bug #11760197.
Conversion failure of “zero” dates in strict SQL mode could cause a server exit. (Bug #18840123)
        Modulo operations on DECIMAL
        values in some cases could overflow and cause a server exit.
       (Bug #18839617)
        Enabling optimizer trace could cause a server exit for queries
        with a subquery in a HAVING clause.
       (Bug #18791851)
        SHA and MD5 functions failed for operations using the internal
        filename character set and could cause a
        server exit.
       (Bug #18786138)
Large arguments passed to mysqldump could lead to buffer overflow and program exit. (Bug #18779944)
If a materialized subquery read from a view, and contained an inner subquery having an outer reference to a column of the view, results could be incorrect. (Bug #18770217)
        Passing bad arguments to SHA2()
        could cause a server exit.
       (Bug #18767104)
        Spatial operations on InnoDB tables could
        fail attempting to access nonexistent index statistics.
       (Bug #18743725)
        ORDER BY of a GIS function that was given
        invalid arguments could cause a server exit.
       (Bug #18701868)
        The code for processing the gb18030 character
        set had a too-strict assertion for single-character invalid
        characters.
       (Bug #18700668)
After a metadata change, a reprepared trigger could cause a server exit or prune an incorrect partition. (Bug #18684393)
mysql_secure_installation ignored options defined after an unrecognized option. (Bug #18659533)
        VALIDATE_PASSWORD_STRENGTH()
        could enter an infinite loop for some arguments.
       (Bug #18636291)
        ALTER TABLE on a partitioned
        table could result in the wrong storage engine being written
        into the table's .frm file and displayed in
        SHOW CREATE TABLE.
       (Bug #18618561)
The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756, Bug #72446, Bug #18665853)
Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms. (Bug #18593044)
        For conditions on the form t.key NOT IN (c1, c2,
        ...), if one or more of the c1,
        c2 was NULL, the optimizer
        generated incorrect range predicates, possibly yielding
        incorrect results.
      
        The range optimizer would build predicates for empty in-lists
        (because NULL values are removed from
        NOT IN (in-list)).
       (Bug #18556403, Bug #18715670)
After conversion of an in-memory internal temporary table to disk, the server could use a pointer to the old table, resulting in a server exit. (Bug #18535226)
For queries executed using Loose Index Scan, incorrect cost estimates could be produced if index statistics were unavailable. (Bug #18497308)
        Setting default_storage_engine
        to a bad value could cause server failure later.
       (Bug #18487724)
        In debug builds, MAKE_SET()
        within a GROUP BY clause raised an assertion.
       (Bug #18487060)
In debug builds, subquery optimization could be overly aggressive about raising an assertion. (Bug #18486607)
In debug builds, a qsort operation on decimal values could raise an assertion. (Bug #18486249)
        For debug builds, an assertion was raised for attempts using a
        cursor within a stored routine to fetch a large value
        (INT) which cannot fit into a variable
        (TINYINT).
       (Bug #18484649)
        MOD for very small decimal right-hand
        arguments could cause a server exit.
       (Bug #18469276)
        With the max_heap_table_size
        system variable set to a large value (20GB), creation of a
        temporary table or a table using the MEMORY
        storage engine caused a server exit.
       (Bug #18463911)
        mysql_session_track_get_first()
        and
        mysql_session_track_get_next()
        returned information only when the type
        argument was SESSION_TRACK_SYSTEM_VARIABLES,
        and returned information for all types, not just
        SESSION_TRACK_SYSTEM_VARIABLES. Now they
        return information of the type requested and only that type.
       (Bug #18463441)
        For mysql_upgrade, specifying the
        --defaults-extra-file with a nonexisting file
        caused a segmentation fault on some platforms.
       (Bug #18443096)
        Assigning some values to the
        session_track_system_variables
        system variable could cause a server exit.
       (Bug #18405677)
        mysql_install_db could hang while reading
        /dev/random to generate a random
        root password.
       (Bug #18395378)
        EXPLAIN FOR
        CONNECTION showed an incorrect filtering value for
        dynamic range queries.
       (Bug #18395059)
        The client library now includes a call to
        X509_verify_cert_error_string() in the SSL
        certificate verification code, to be more robust in detecting
        invalid certificates.
       (Bug #18384260)
        Queries that use AES_ENCRYPT(),
        AES_DECRYPT(), or
        RANDOM_BYTES() cannot be cached
        but were permitted to enter the query cache.
       (Bug #18383169)
        If MySQL was built with the
        -DINSTALL_LIBDIR=lib64 option,
        mysql_config did not work if the MySQL
        package was unpacked into a location with a different
        installation prefix. Also, mysql_config did
        not work for some RPM builds because it used an incorrect
        installation prefix.
       (Bug #18382225)
Plugin registration code in the embedded server (compiled without the Performance Schema) failed for plugins compiled with the Performance Schema. (Bug #18363910)
For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
        The HAVE_IB_LINUX_FUTEX
        CMake check failed due to a missing include
        file.
       (Bug #18353271)
        After a code reorganization in MySQL 5.7.4, ORDER
        BY for multiple-table UPDATE
        statements was ignored.
       (Bug #18352634)
        The addition in MySQL 5.7.4 of session state information to the
        OK packet of the client/server protocol caused the
        mysql->info member to be missing a
        terminating null terminator.
       (Bug #18349102)
Improper linking of join caches by the optimizer could lead to a server exit. (Bug #18335908)
In debug builds, lack of proper object initialization of decimal objects caused an assertion to be raised. (Bug #18335446)
        UNCOMPRESSED_LENGTH() could
        return NULL when it should not have.
       (Bug #18335269)
On Windows, some test cases ran too slowly due to mysqltest not testing properly for server termination. (Bug #18330694)
        The COM_RESET_CONNECTION command did not
        reset some session system variables:
        rand_seed1,
        rand_seed2,
        timestamp. Also, it did not
        clear warnings, and, although it reset the
        profiling variable, it did not
        reset profiling information.
       (Bug #18329348, Bug #18329560, Bug #18328396, Bug #18329452)
        Certain INFORMATION_SCHEMA queries could
        cause a server exit.
       (Bug #18319790)
        EXPLAIN for some full-text
        queries could raise an assertion.
       (Bug #18313651)
Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
        DELETE is not allowed on views
        defined as joins on the base tables. However, MySQL incorrectly
        permitted REPLACE (which is like
        a combination of DELETE and
        INSERT) on such views.
       (Bug #18286777)
        For debug builds, a 0x00 character in a
        full-text query string that used the
        ujis_japanese_ci,
        utf8mb4_turkish_ci, or
        eucjpms_bin collation could raise an
        assertion.
       (Bug #18277305)
        innobase_strnxfrm() wrote one byte too many.
       (Bug #18277082)
        On Windows, use of the gb18030_unicode_520_ci
        caused a server exit.
       (Bug #18271429)
        The internal likely() and
        unlikely() macros conflicted with Boost
        symbols. To resolve this, the macros were converted to inline
        functions.
       (Bug #18242233)
        If the left-hand-side of an IN predicate was
        a scalar subquery but returned no row, the server could exit.
       (Bug #18223655, Bug #18447874)
        For queries involving an AND of two geometry
        ranges, the optimizer could decide no index was usable but try
        to use it anyway, resulting in a server exit.
       (Bug #18220153)
        Argument checking for a memmove() call in
        my_net_read() was improved.
       (Bug #18184793)
        mysql_upgrade invoked the
        mysql and mysqlcheck
        clients and the command arguments could be visible to other
        processes. This issue is addressed by the reimplementation of
        mysql_upgrade to communicate directly with
        the server, a change described elsewhere in these release notes.
       (Bug #18180398)
yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
        yaSSL code had an opendir() without a
        corresponding closedir().
       (Bug #18178997, Bug #17201924)
        EXPLAIN on a query with an
        EXISTS subquery containing a
        UNION could cause a server exit. Multiple
        executions of a prepared EXPLAIN on a
        UNION of subqueries could cause a server
        exit.
       (Bug #18167356)
mysqladmin password masked the old password given on the command line, but not the new password. (Bug #18163964)
        For InnoDB tables, boolean full-text queries
        for terms ending with * could return
        incorrect results.
       (Bug #18128757)
For XA transactions, -1 could be assigned as the format ID part of an XID value, resulting in mishandling (server hang or exit) of concurrent XA statements. (Bug #18107853)
The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)
        For full-text queries on InnoDB tables,
        attempts to access deleted document IDs could lead to a server
        exit.
       (Bug #18079671)
        The optimizer could compute a negative cost value when
        constructing an execution plan for MERGE
        table queries.
       (Bug #18066518)
        Executing a correlated subquery on an ARCHIVE
        table which has an AUTO_INCREMENT column
        caused the server to hang.
       (Bug #18065452)
        Calling
        mysql_get_server_version() with
        an invalid connection handler argument caused the client to
        exit. Now it returns 0 and reports a
        CR_COMMANDS_OUT_OF_SYNC error.
       (Bug #18053212)
        MyISAM temporary files could be used to mount
        a code-execution attack.
       (Bug #18045646)
If the optimizer chose to perform an index scan, in some cases it could choose a noncovering rather than a covering index. (Bug #18035906)
        The CMake
        -DWITHOUT_PARTITION_STORAGE_ENGINE=1 option did
        not work. As part of fixing this problem, a preferred syntax for
        disabling storage engines was implmented. The syntax
        -DWITH_
        is now preferred to
        engine_STORAGE_ENGINE=0-DWITHOUT_.
        For example, use:
      engine_STORAGE_ENGINE=1
-DWITH_EXAMPLE_STORAGE_ENGINE=0 -DWITH_FEDERATED_STORAGE_ENGINE=0 -DWITH_PARTITION_STORAGE_ENGINE=0
Rather than:
-DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 -DWITHOUT_FEDERATED_STORAGE_ENGINE=1 -DWITHOUT_PARTITION_STORAGE_ENGINE=1
(Bug #17947926)
The C client library could leak memory when client plugins were used. (Bug #17933308)
        For debug builds, DROP FUNCTION
        with a too-long function name raised an assertion.
       (Bug #17903490)
        A BEFORE UPDATE trigger could insert
        NULL into a NOT NULL
        column.
       (Bug #17864349)
        A UNION ALL
        query with SQL_CALC_FOUND_ROWS and a
        LIMIT with an offset for one query block
        reported an incorrect number of found rows.
       (Bug #17833261)
        For debug builds, a DELETE
        statement with a subquery that returned multiple rows in a
        context requiring a scalar subquery could raise a diagnostic
        area assertion.
       (Bug #17787664)
        Using an outer reference in a GROUP BY or
        ORDER BY clause in a subquery could cause a
        server exit.
       (Bug #17748273)
        For queries that selected from the
        events_statements_current
        Performance Schema table, adding an ORDER BY
        clause could produce incorrect results.
       (Bug #17729044)
        A (rare) deadlock could occur between
        LOCK_thd_data and the
        InnoDB trx_sys mutex. One
        thread could read a query string while it was being removed by
        another thread.
       (Bug #17606098)
        On Windows, calling mysql_thread_init() call
        without mysql_init() caused the client to
        exit. windows. Now it returns a nonzero result because it is an
        error to call mysql_thread_init() before the
        client library is initialized with
        mysql_library_init().
       (Bug #17514920)
        For REPLACE on a view, a row
        being replaced in a view might conflict with one or more rows in
        the base table, some of which might not be accessible by the
        view. In some cases, rows inaccessible by the view could be
        replaced.
       (Bug #17487701)
        mysqldump could create table definitions in
        the dump file that resulted in Too many
        columns errors when reloading the dump file.
       (Bug #17477959)
        Using LOAD DATA to load
        fixed-length data into a view could cause a server exit.
       (Bug #17458965)
The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)
        UPDATE statements that modified
        full-text indexes could cause a server exit.
       (Bug #17457755)
        Sending a SIGQUIT or
        SIGINT signal to mysql
        could result in a glibc  double free or
        corruption error.
       (Bug #17297324)
        A server could have its socket file taken over by a second
        server listening on different TCP/IP port but the same socket
        file. The socket file also would be unlinked by normal shutdown
        of the second server. To avoid this, the server now uses a lock
        file with the same name as the socket file and a
        .lock suffix. (For example,
        /tmp/mysql.sock has a lock file of
        /tmp/mysql.sock.lock.) The lock file
        contains the process ID of the server process that created the
        socket file.
       (Bug #17286856)
        If a query had both MIN()/MAX() and
        aggregate_function(DISTINCT)SUM(DISTINCT)) and was executed
        using Loose Index Scan, the result values of
        MIN()/MAX() were set improperly.
       (Bug #17217128)
        For UNION statements, the
        rows-examined value was calculated incorrectly. This was
        manifest as too-large values for the
        ROWS_EXAMINED column of Performance Schema
        statement tables (such as
        events_statements_current).
       (Bug #17059925)
When joining one large table without indexes to a number of smaller tables with indexes, the optimizer chose to join on the large table as the last table, causing a large number of large table scans. (Bug #16838146)
        Row constructor arguments to
        INTERVAL() could cause a server
        exit.
       (Bug #16439419)
        An assertion could be raised when creating a index on a prefix
        of a TINYBLOB or
        GEOMETRY column in an
        InnoDB column.
       (Bug #16368875, Bug #18776592, Bug #17665767)
mysql_config_editor left some files open when they were no longer needed, resulting in Valgrind warnings. (Bug #16368498)
        Several issues related to the
        ONLY_FULL_GROUP_BY SQL mode
        were corrected:
      
            With ONLY_FULL_GROUP_BY
            enabled, some valid queries were rejected if the accessed
            table was replaced by a view.
          
            Queries of the form SELECT DISTINCT
             qualify as
            forbidden by SQL2003 (hidden col1 ... ORDER BY
            col2ORDER BY
            columns combined with DISTINCT), but were
            not rejected with the
            ONLY_FULL_GROUP_BY SQL
            mode enabled.
          
(Bug #16021396, Bug #18993257, Bug #13581713)
        The change made in MySQL 5.7.0 to display the XID value in
        hexadecimal for XA
        RECOVER if it contained nonprintable characters was
        reverted because it caused problems for some clients. Now the
        statement takes an optional CONVERT XID
        keyword so that clients can request the XID value in hexadecimal
        on demand.
       (Bug #14670465)
Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit. (Bug #12368495, Bug #18315770)
        Executing a DELETE statement on a table with
        no key in safe-update mode resulted in an
        ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE
        error. For debug builds, using IGNORE in the
        statement resulted in an assertion being raised.
       (Bug #74493, Bug #19873291)
        Binary MySQL distributions for OS X 10.8 and up now bundle the
        MySQL.prefPane and
        MySQLStartupItem.pkg tools into the main
        package as configurable options instead of separate packages.
       (Bug #74123, Bug #19701502)
        For debug builds, a SELECT under
        load from the
        events_statements_current
        Performance Schema table could raise an assertion.
       (Bug #73530, Bug #19419463)
        mysql_secure_installation failed to run
        properly if the root account authentication
        plugin was sha256_password.
       (Bug #73148, Bug #19127636)
        The server did not take the
        lower_case_table_names value
        into account in determining the database directory from which to
        read the db.opts file, and thus could read
        the file from an incorrect directory.
       (Bug #72900, Bug #18923685)
        SHA2() failed to return
        NULL if the hash-length argument was
        NULL or not one of the permitted values.
       (Bug #72856, Bug #18899869)
        mysql_install_db failed to create the initial
        root account if
        autocommit was disabled.
       (Bug #72724, Bug #18911807)
        The mysql client displayed
        gb18030 data incorrectly.
       (Bug #72573, Bug #18726196)
        The gb18030_chinese_ci collation treated
        'Y' equal to '~'.
       (Bug #72565, Bug #18729428)
        The query cache was not invalidated for a table when a
        CASCADE DELETE or CASCADE
        UPDATE referential constraint was specified and the
        database name or table name contained special characters.
       (Bug #72547, Bug #18710853)
        NOW(
        in a view definition was stored as N)NOW(),
        thus losing the fractional seconds part.
       (Bug #72472, Bug #18675237)
If a prepared statement being executed produced an error, the server failed to write the statement to the general query log. (Bug #72375, Bug #18616826)
        A new CMake option,
        SUNPRO_CXX_LIBRARY, enables
        linking against libCstd instead of
        stlport4 on Solaris 10 or later. This works
        only for client code because the server depends on C++98.
        Example usage:
      
cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd
(Bug #72352, Bug #18605389)
        A SELECT statement using a
        subquery with UNION and ORDER
        BY did not permit use of an alias in the outer
        statement.
       (Bug #72189, Bug #18498344)
        UNION queries with an aggregate
        function in an ORDER BY clause were not
        rejected as they should be. Now such queries are rejected with
        an ER_AGGREGATE_ORDER_FOR_UNION
        error. Example:
      
SELECT 1 AS foo UNION SELECT 2 ORDER BY MAX(1);
        A nonaggregated query with an ORDER BY
        applied to it cannot contain aggregate functions, but was not
        rejected as it should be. Now such queries are rejected with an
        ER_AGGREGATE_ORDER_NON_AGG_QUERY
        error. Example:
      
SELECT a FROM t1 ORDER BY COUNT(*);
(Bug #72174, Bug #18503515, Bug #72512, Bug #18694751)
        MOD operations on a
        DECIMAL value with leading zeros
        could produce incorrect results.
       (Bug #72100, Bug #18509896)
        mysqlslap accepted an
        --iterations option value of 0, which resulted
        in a divide-by-zero error. The minimum option value now is 1.
        Thanks to Tsubasa Tanaka for the patch.
       (Bug #72082, Bug #18430704)
        mysql_upgrade could fail if the
        mysql.user table contained multiple accounts
        with the same user name and host name where the host name
        differed in lettercase. This is still not permitted, but now
        mysql_upgrade prints a more informative error
        message to indicate the nature of the problem:
      
ERROR 1644 (45000): Multiple accounts exist foruser_name,host_namethat differ only in Host lettercase; remove all except one of them
(Bug #72066, Bug #18415196)
        ER_CANT_CREATE_GEOMETRY_OBJECT
        was treated as a fatal error, thus not catchable with condition
        handlers.
       (Bug #72064, Bug #18413646)
        Some comparisons between BIGINT signed and
        unsigned values could yield incorrect results.
       (Bug #72046, Bug #18408499)
        For IN() predicates with values different
        from the key data value, the optimizer sometimes used a table
        scan when it could do a range scan.
       (Bug #71962, Bug #18364815)
        mysql_config_editor exited when given an
        empty argument to the --login-path option.
       (Bug #71837, Bug #18311024, Bug #18830493)
Upgrades using RPM packages could change the ownership of an installation directory. (Bug #71715, Bug #18281535)
        The threads Performance Schema
        table displayed a PROCESS_ID value of
        NULL for replication threads. Now it displays
        the same ID as SHOW PROCESSLIST
        and the
        INFORMATION_SCHEMA.PROCESSLIST
        table.
       (Bug #71682, Bug #18259356)
        In the DIGEST_TEXT column of Performance
        Schema statement events tables, references to system variables
        of the form
        @@ were
        stored as var_name@ @
        .
       (Bug #71634, Bug #18304086)var_name
        For mysqldump, dump and restore operations
        failed for database names that contained backslash
        ('\'). Thanks to Xiaobin Lin for the patch.
       (Bug #71437, Bug #18109728)
        A simultaneous OPTIMIZE TABLE and
        online ALTER TABLE on the same
        InnoDB table could result in deadlock.
       (Bug #71433, Bug #18110156)
        XA START after a
        server restart with the exising XID followed by
        XA COMMIT failed
        to commit.
       (Bug #71352, Bug #18068253)
Proxy users were unable to execute statements if the proxied user password had expired. (Bug #71337, Bug #18057562)
MySQL did not compile with Bison 3. (Bug #71250, Bug #18017820, Bug #18978946)
        Deadlock could occur if three threads simultaneously performed
        INSTALL PLUGIN,
        SHOW VARIABLES, and
        mysql_change_user().
       (Bug #71236, Bug #18008907, Bug #72870, Bug #18903155)
        A statement of the following form broke row-based replication
        because it created a table having a field of data type
        BIGINT with a display width of 3000, which is
        beyond the maximum acceptable value of 255:
      
CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;
(Bug #71179, Bug #17994219)
        When MySQL runs as service on Windows,
        NTService.Stop() initiates shutdown and exit
        events during shutdown. After a code reorganization in MySQL
        5.7.3, a call to clean_up() was missed,
        resulting in initiation of crash recovery.
       (Bug #71104, Bug #17980260)
        If there was a predicate on a column referenced by
        MIN() or
        MAX() and that predicate was not
        present in all the disjunctions on key parts earlier in the
        compound index, Loose Index Scan returned an incorrect result.
       (Bug #71097, Bug #17909656)
Invalid memory access could occur when using prepared statements if a mysql client connection was lost after statement preparation was complete and there was at least one statement that was in initialized state but not prepared yet. (Bug #70429, Bug #17512527)
        Client auto-reconnect did not work for clients linked against
        libmysqlclient, even with
        MYSQL_OPT_RECONNECT enabled.
      
        Also, if a FEDERATED table was accessed after
        wait_timeout expired, a Lost
        connection to MySQL server error occurred without an
        attempt to re-establish the connection.
       (Bug #70026, Bug #17309863, Bug #14874, Bug #11745408)
        Full-text queries on MyISAM tables that
        included a LIMIT clause but no
        WHERE clause could return too few rows.
       (Bug #69908, Bug #17261347)
Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)
        On Windows, REPAIR TABLE and
        OPTIMIZE TABLE failed for
        MyISAM tables with .MYD
        files larger than 4GB.
       (Bug #69683, Bug #17235179)
        For logging of prepared statements to the general query log, the
        Execute line was logged after statement
        execution, not before.
       (Bug #69453, Bug #16953758, Bug #20536590)
        Calls to UNCOMPRESS() produced
        Valgrind warnings during verification of the zip header of the
        compressed data.
       (Bug #69202, Bug #18693654)
mysql_tzinfo_to_sql mishandled some values from the abbreviation list (read from the timezone information file) due to failure to account for the null character appended to the end of the char array. (Bug #68861, Bug #16664462)
Some statements could be written to the slow query log twice. (Bug #68626, Bug #16467055)
File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)
        In some cases, a successful CREATE
        VIEW could add invalid parentheses to expressions in
        the view definition.
       (Bug #67791, Bug #15948263)
If the general query log or slow query log file was set to a FIFO or socket file, and the file reader went away, the server stopped executing statements. Now the server detects such files, logs an error message, and continues with the appropriate log disabled. (Bug #67088, Bug #14757009)
        For non-debug builds of several client programs, the
        --help message did not correctly indicate that
        the --debug, --debug-check,
        and --debug-info apply only for debug builds.
       (Bug #66854, Bug #16272328)
Notification of events for the general log were received by the audit log plugin only if the general query log was enabled. Now notifications are posted regardless of whether the general query log is enabled. (Bug #60782, Bug #12368204, Bug #20536590, Bug #75796, Bug #20479643)
        Queries that used GROUP BY INSERT() could
        produce spurious duplicate-key errors.
       (Bug #58081, Bug #11765149)
mysql_install_db could fail if not invoked in the MySQL installation base directory. (Bug #54034, Bug #11761529)
        With big_tables enabled, queries that used
        COUNT(DISTINCT) on a simple join with a
        constant equality condition on a non-duplicate key returned
        incorrect results.
       (Bug #52582, Bug #11760197)
References: See also: Bug #18853696.
        LOAD DATA
        LOCAL could use all CPU if import errors occurred when
        there were no line delimiters.
       (Bug #51840, Bug #11759519)
        For an existing nondynamic (built-in) plugin, the error message
        for an attempted UNINSTALL PLUGIN
        was misleading (the plugin does not exist). Now the message
        indicates that built-in plugins cannot be uninstalled.
       (Bug #51771, Bug #11759453)
        LIKE matches failed for code points
        of HALF WIDTH KATAKANA in the sjis and
        cp932 character sets.
       (Bug #47641, Bug #11755818)
        The server failed to produce an error for
        INSERT statements that provided
        no column names but did provide column values.
       (Bug #20943, Bug #11745889, Bug #18064775)
References: This issue is a regression of: Bug #16820562.
        Connection IDs are 32-bit unsigned integers, beginning at 1.
        When the server assigns connection IDs and reaches the top of
        the 32-bit range, it rolls the value over to begin at 1 again.
        It was possible that the server would assign a connection ID to
        a new thread while that ID was still in use by an existing
        thread, if the old thread was particularly long running. For
        such cases, reference to the ID becomes ambiguous. For example,
        it cannot reliably be determined for
        KILL
         which thread
        to kill, which could lead to undefined behavior. This behavior
        has been corrected so that in-use IDs are not reused.
       (WL #7293)connection_id