Documentation Home
MySQL 8.0 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 4.2Mb
PDF (A4) - 4.3Mb


MySQL 8.0 Release Notes  /  Changes in MySQL 8.0.16 (2019-04-25, General Availability)

Changes in MySQL 8.0.16 (2019-04-25, General Availability)

For general information about upgrades, downgrades, platform support, etc., please visit https://dev.mysql.com/doc/relnotes/mysql/8.0/en/.

Account Management Notes

  • Previously, users who had the DROP ROLE privilege could use the DROP ROLE statement to drop locked or unlocked accounts. Now, users who have the DROP ROLE privilege can use DROP ROLE only to drop accounts that are locked (unlocked accounts are presumably user accounts used to log in to the server and not just as roles). Users who have the CREATE USER privilege can use DROP ROLE to drop accounts that are locked or unlocked. (Bug #28953158, Bug #93263)

  • Several changes have been made to MySQL account-management capabilities:

    • MySQL now incorporates the concept of user account categories, with system and regular users distinguished according to whether they have the new SYSTEM_USER privilege:

      • System users are users who possess the SYSTEM_USER privilege. A system user can perform operations on both system and regular accounts.

      • Regular users are ordinary users who do not possess the SYSTEM_USER privilege. A regular user can perform operations on regular accounts, but not system accounts.

      If a user has the appropriate privileges to perform a given operation on regular accounts, SYSTEM_USER enables the user to also perform the operation on system accounts. SYSTEM_USER does not imply any other privilege, so the ability to perform a given account operation remains predicated on possession of any other required privileges. For example, if a user can grant the SELECT and UPDATE privileges to regular accounts, then with SYSTEM_USER the user can also grant SELECT and UPDATE to system accounts.

      The distinction between system and regular accounts enables better control over certain account administration issues by protecting accounts that have the SYSTEM_USER privilege from accounts that do not have the privilege. For example, the CREATE USER privilege enables not only creation of new accounts, but modification and removal of existing accounts. Without the system user concept, a user who has the CREATE USER privilege can modify or drop any existing account, including the root account. The concept of system user enables restricting modifications to the root account (itself a system account) so they can be made only by system users. Regular users with the CREATE USER privilege can still modify or drop existing accounts, but only regular accounts.

      Other operational implications of the SYSTEM_USER privilege:

      • A session that has the SYSTEM_USER privilege can be killed only by users who have the SYSTEM_USER privilege, in addition to any other required privileges.

      • An account that has the SYSTEM_USER privilege can be specified as the DEFINER for a stored object only by users who have the SYSTEM_USER privilege, in addition to any other required privileges.

      • A role that has the SYSTEM_USER privilege cannot be listed in the value of the mandatory_roles system variable.

      For more information, see Account Categories.

    • Previously, it was not possible to grant privileges that apply globally except for certain schemas. This is now possible if the new partial_revokes system variable is enabled. For example, the following statements enable an account to select from or insert into any table except those in the mysql system schema:

      SET PERSIST partial_revokes = ON;
      GRANT SELECT, INSERT ON *.* TO u1;
      REVOKE SELECT, INSERT ON mysql.* FROM u1;

      The server records partial revokes by adding a Restrictions attribute to the User_attributes column of the mysql.user system table. SHOW GRANTS includes REVOKE statements in its output to indicate partial revokes.

      Note

      Enabling partial_revokes causes MySQL to treat unescaped _ and % SQL wildcard characters in schema names as literal characters, just as if they had been escaped as \_ and \%. Because this changes the interpretation of privilege assignments, it may be advisable to avoid unescaped wildcard characters in schema privilege assignments for MySQL installations where partial_revokes may be enabled.

      For more information, see Privilege Restriction Using Partial Revokes.

    • The GRANT statement has a new AS user [WITH ROLE] clause that specifies additional information about the privilege context to use for statement execution. This syntax is visible at the SQL level, although its primary purpose is to enable uniform replication across all nodes of grantor privilege restrictions imposed by partial revokes, by causing those restrictions to appear in the binary log.

      For more information, see GRANT Statement.

    (WL #12098, WL #12364, WL #12820)

C API Notes

Character Set Support

  • MySQL now supports a new Chinese collation, utf8mb4_zh_0900_as_cs, for the utf8mb4 Unicode character set. utf8mb4_zh_0900_as_cs is the first Chinese language-specific collation available for Unicode in MySQL. This collation is accent sensitive and case sensitive. Its characteristics are similar to utf8mb4_0900_as_cs except that language-specific rules take precedence where applicable. For more information, see Unicode Character Sets. (WL #11825)

Compilation Notes

  • CMake now causes the build process to link with the llvm lld linker for Clang if it is available and not explicitly disabled. To disable use of this linker, specify the -DUSE_LD_LLD=OFF option. (Bug #29264211)

  • Builds on EL6 and EL7 now try to use the compiler in devtoolset-8 rather than devtoolset-7. (Bug #29198846)

  • The minimum version of the Boost library for server builds is now 1.69.0. (Bug #29114233)

  • The configuration-time check for Visual Studio 2017 was not specific enough. The check for MySQL compilation now requires at least Visual Studio update 15.8, which is version number 1915. (Bug #28970895)

  • MySQL now can be compiled using C++14. The following minimum version requirements apply for compiler support:

    • GCC 5.3 (Linux)

    • Clang 4.0 (FreeBSD)

    • XCode 9 (macOS)

    • Developer Studio 12.6 (Solaris)

    • Visual Studio 2017 (Windows)

    (WL #12424)

Configuration Notes

  • MySQL configuration now requires a minimum CMake version of 3.4.3. This requires the use of cmake3 rather than cmake on some Red Hat and Oracle Linux platforms. (Bug #29246216)

  • The WITH_LZMA CMake option was removed. (Bug #29153932, Bug #93755)

  • The EXCLUDE_FROM_ALL option is now used in CMake configuration as appropriate so that libraries are built only if they are actually used by any executable. (Bug #29052599)

  • The new WITH_JEMALLOC CMake option indicates whether to link with -ljemalloc. If enabled, built-in malloc(), calloc(), realloc(), and free() routines are disabled. The default is OFF. (Bug #29027974)

  • The new WITH_LSAN CMake option indicates whether to run LeakSanitizer, without AddressSanitizer. The default is OFF. (Bug #28936574)

  • The new WITH_ROUTER CMake option indicates whether to build MySQL Router. The default is ON. (Bug #28759234)

  • MySQL Server now supports a --validate-config option that enables the startup configuration to be checked for problems without running the server in normal operational mode. For more information, see Server Configuration Validation. (WL #12360)

Deprecation and Removal Notes

  • The TempTable storage engine now always uses InnoDB to manage internal temporary tables on disk, and the choice of storage engine employed for this task is no longer user-configurable. The internal_tmp_disk_storage_engine system variable has been removed. (Bug #91377, Bug #28234637, WL #11974)

    References: See also: Bug #28081038, Bug #82556, Bug #27408352.

Installation Notes

  • Previously, after installation of a new version of MySQL, the MySQL server automatically upgraded the data dictionary tables at the next startup, after which the DBA was expected to invoke mysql_upgrade manually to upgrade the system tables in the mysql schema, as well as objects in other schemas such as the sys schema and user schemas.

    The server now performs the tasks previously handled by mysql_upgrade. After installation of a new MySQL version, the server now automatically performs all necessary upgrade tasks at the next startup and is not dependent on the DBA invoking mysql_upgrade. In addition, the server updates the contents of the help tables (something mysql_upgrade did not do). A new --upgrade server option provides control over how the server performs automatic data dictionary and server upgrade operations. For more information, see Upgrading MySQL.

    This change to the upgrade procedure results in some deprecations:

    • mysql_upgrade is deprecated because it is no longer necessary.

    • The --no-dd-upgrade server option is deprecated because the --upgrade option supersedes it.

    mysql_upgrade and the --no-dd-upgrade option will be removed in a future MySQL version. (Bug #28146052, Bug #28162609, Bug #91205, Bug #29185739, Bug #27740692, Bug #28547424, Bug #91961, WL #12413, WL #12918)

Packaging Notes

  • The Docker image for MySQL Cluster 8.0 is now available for download. (Bug #30010921, Bug #96084)

  • Binary packages that include curl rather than linking to the system curl library now use curl 7.64.0. (Bug #29357198)

  • The Henry Spencer regex library (extra/regex) is no longer used by MySQL 8.0 and is no longer present in source distributions. (Bug #29192306)

  • RPM packages now have dependencies on libtirpc and rpcgen because newer versions of glibc do not include Sun RPC. (Bug #28995257)

  • The support-files/magic file was removed from the MySQL source tree. Most MySQL file formats are covered by operating system file type capabilities. (Bug #18335080, Bug #71898)

  • MySQL now provides Minimal Install Linux generic binary download packages for MySQL Server and the Test Suite. Minimal install packages exclude debug binaries and are stripped of debug symbols, making them significantly smaller than the regular Linux generic binary packages. Downloads are available at https://dev.mysql.com/downloads/.

  • The Docker image for MySQL Enterprise Edition is now available for download from My Oracle Support.

Parser Notes

  • The parser no longer accepts the undocumented and nonstandard = alias_name syntax for specifying table aliases. (Bug #29205289)

  • The parser is now permits several additional nonreserved keywords to be used as labels within stored programs that previously were restricted from such use: ACCOUNT, ALWAYS, BACKUP, CLOSE, FORMAT, GROUP_REPLICATION, HOST, INVISIBLE, OPEN, OPTIONS, OWNER, PARSER, PORT, REMOVE, RESTORE, ROLE, SECONDARY, SECONDARY_ENGINE, SECONDARY_LOAD, SECONDARY_UNLOAD, SECURITY, SERVER, SOCKET, SONAME, UPGRADE, VISIBLE, WRAPPER. (Bug #29033659)

  • The parser accepted ODBC escape syntax for outer joins ({ OJ outer_join }), but also accepted identifiers other than OJ. The parser now accepts only OJ.

    Note

    OJ now is a nonreserved keyword.

    (Bug #22320942)

Performance Schema Notes

  • The new Performance Schema keyring_keys table exposes metadata for keys in the MySQL Keyring. Key metadata includes key IDs, key owners, and backend key IDs. The keyring_keys table does not expose any sensitive keyring data such as key contents. See The keyring_keys table. (WL #11543)

Plugin Notes

  • MySQL now includes a ddl_rewriter plugin that modifies CREATE TABLE statements received by the server before it parses and executes them. The plugin removes ENCRYPTION, DATA DIRECTORY, and INDEX DIRECTORY clauses, which may be helpful when restoring tables from SQL dump files created from databases that are encrypted or that have their tables stored outside the data directory. For example, the plugin may enable restoring such dump files into an unencrypted instance or in an environment where the paths outside the data directory are not accessible. When installed, ddl_rewriter exposes the Performance Schema memory/rewriter/ddl_rewriter instrument for tracking plugin memory use. For more information, see The ddl_rewriter Plugin. (WL #12668)

Security Notes

  • Previously, if the grant tables were corrupted, the MySQL server wrote a message to the error log but continued as if the --skip-grant-tables option had been specified. This resulted in the server operating in an unexpected state unless --skip-grant-tables had in fact been specified. Now, the server stops after writing a message to the error log unless started with --skip-grant-tables. (Starting the server with that option enables you to connect to perform diagnostic operations.) (Bug #29394501, Bug #94394, WL #12971)

  • The OpenSSL libraries bundled with MySQL on some platforms (Windows, macOS, and Generic Linux) have been upgraded to version 1.0.2r. On all other platforms, MySQL uses the system installed OpenSSL. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. (Bug #28988091)

  • Granting roles to anonymous users is no longer supported because such roles caused problematic behavior. (Bug #28910120)

  • OpenSSL 1.1.1 supports the TLS v1.3 protocol for encrypted connections, and MySQL now supports TLS v1.3 as well, if both the server and client are compiled using OpenSSL 1.1.1 or higher:

    • Some TLSv1.3 ciphersuites are enabled by default. The tls_ciphersuites system variable enables explicitly specifying which TLSv1.3 ciphersuites the server permits.

    • The --tls-ciphersuites client option specifies which TLSv1.3 ciphersuites a client permits. This option applies to these programs: mysql, mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlpump, mysqlshow, mysqlslap, mysqltest, mysql_secure_installation, and mysql_upgrade.

    • The mysql_options() C API function has a new MYSQL_OPT_TLS_CIPHERSUITES option that specifies from within the client library which TLSv1.3 ciphersuites a client program permits.

    For more information, see Encrypted Connection TLS Protocols and Ciphers.

    Note

    Group Replication does not support TLSv1.3.

    (WL #12361)

  • The TLS context the server uses for new connections now is reconfigurable at runtime. This capability may be useful, for example, to avoid restarting a MySQL server that has been running so long that its SSL certificate has expired. Dynamic SSL reconfigurability is based on these changes:

    For more information, see Server-Side Runtime Configuration and Monitoring for Encrypted Connections.

    Thanks to Facebook for submitting code for a similar feature (although the code was not used). (WL #11541)

    References: See also: Bug #27980097.

  • In MySQL 8.0, the default authentication plugin was changed from mysql_native_password to caching_sha2_password. Because caching_sha2_password provides a superset of the capabilities of the sha256_password authentication plugin, sha256_password is now deprecated and will be removed in a future MySQL version. MySQL accounts that authenticate using sha256_password should be migrated to use caching_sha2_password instead. (WL #12694)

Spatial Data Support

SQL Syntax Notes

  • Incompatible Change: In MySQL 5.7, specifying a FOREIGN KEY definition for an InnoDB table without a CONSTRAINT symbol clause, or specifying the CONSTRAINT keyword without a symbol, causes InnoDB to use a generated constraint name. That behavior changed in MySQL 8.0, with InnoDB using the FOREIGN KEY index_name value instead of a generated name. Because constraint names must be unique per schema (database), the change caused errors due to foreign key index names that were not unique per schema. To avoid such errors, the new constraint naming behavior has been reverted, and InnoDB once again uses a generated constraint name.

    For consistency with InnoDB, the NDB storage engine now uses a generated constraint name if the CONSTRAINT symbol clause is not specified, or the CONSTRAINT keyword is specified without a symbol. In NDB releases based on MySQL 5.7 and earlier MySQL 8.0 releases, NDB used the FOREIGN KEY index_name value.

    The changes described above may introduce incompatibilities for applications that depend on the previous foreign key constraint naming behavior. (Bug #29173134)

  • Previously, MySQL permitted a limited form of CHECK constraint syntax, but parsed and ignored it. MySQL now implements the core features of table and column CHECK constraints, for all storage engines. Constraints are defined using CREATE TABLE and ALTER TABLE statements. The new INFORMATION_SCHEMA.CHECK_CONSTRAINTS table provides information about CHECK constraints defined on tables. For more information, see CHECK Constraints. (Bug #11744849, Bug #3464, Bug #3465, Bug #11746042, Bug #22759, WL #929)

sys Schema Notes

  • MySQL now includes built-in SQL functions that format or retrieve Performance Schema data, and that may be used as equivalents for existing sys schema stored functions:

    The built-in functions can be invoked in any schema and require no qualifier, unlike the sys functions, which require either a sys. schema qualifier or that sys be the current schema.

    The built-in functions supersede the corresponding sys functions, which now are deprecated and will be removed in a future MySQL version. Applications that use the sys functions should be adjusted to use the built-in functions instead, keeping in mind some minor differences between the sys functions and the built-in functions. See Performance Schema Functions. (WL #7803)

Test Suite Notes

  • mysql-test-run.pl now supports the MTR_UNIQUE_IDS_DIR environment variable, which may be set to specify a unique-IDs directory to be used as the common location for all chroot environments by multiple simultaneous mysql-test-run.pl instances. This enables those instances to avoid conflicts when reserving port numbers. Thanks to Facebook for the contribution. (Bug #29221085, Bug #93950)

  • The my_safe_process program was renamed to mysqltest_safe_process and now is installed with other binaries such as mysqltest rather than with test suite files. (Bug #29198969)

  • These changes to the all_persisted_variables test were implemented:

    • It limits the number of hardcoded values in the test output by putting them into local variables. New patches that are then rebased on top that add new system variables do not need to change as many lines of the original test case, making it easier on the rebase process.

    • It removes entries for bugs that were fixed and modifies the queries to include the system variables that were not tested due to open bugs.

    Thanks to the Facebook team for the contribution. (Bug #29013375, Bug #93478)

X Plugin Notes

  • X Plugin previously returned a StmtExecuteOk message to the client after query cleanup had ended and the session had been deactivated. The message is now returned as soon as the result is known and before query cleanup, which gives a noticeable improvement in performance. (Bug #28997370)

  • X Plugin logged the system message "X Plugin ready for connections" when user connections were not available because preparation of I/O interfaces had failed. (Bug #28906360)

  • Some items in the X Plugin code were not instrumented for the Performance Schema by default. (Bug #28898155)

  • X Protocol now supports the COM_RESET_CONNECTION utility command to reset the session state without re-authenticating or closing the connection. (Bug #28732455)

  • X Plugin produced compilation warnings when the MySQL Server source code was built using the Clang 8 compiler. (Bug #28732158)

Functionality Added or Changed

  • InnoDB: When the amount of memory occupied by the TempTable storage engine exceeds the limit defined by the temptable_max_ram variable, the TempTable storage engine allocates space for internal in-memory temporary tables as memory-mapped temporary files. This behavior is now controlled by the temptable_use_mmap variable, which can be disabled to have the TempTable storage engine use InnoDB on-disk internal temporary tables instead. For more information, see Internal Temporary Table Use in MySQL. (Bug #28944457)

  • InnoDB: undo and purge subsystem counters were added for monitoring background activities associated with undo log truncation. For counter names and descriptions, query the INFORMATION_SCHEMA.INNODB_METRICS table.

    SELECT NAME, SUBSYSTEM, COMMENT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE '%truncate%';

    For information about enabling counters and querying counter data, see InnoDB INFORMATION_SCHEMA Metrics Table. (Bug #28813526, WL #12600)

  • InnoDB: The new innodb_spin_wait_pause_multiplier variable provides greater control over the duration of spin-lock polling delays that occur when a thread waits to acquire a mutex or rw-lock. Delays can now be tuned more finely to account for differences in PAUSE instruction duration on different processor architectures. For more information, see Configuring Spin Lock Polling. (WL #12616)

  • InnoDB: An internal service interface was added to support tracking of modified pages. (WL #11082)

  • InnoDB: The InnoDB data-at-rest encryption feature now supports encryption of the mysql system tablespace. The mysql system tablespace contains the mysql system database and the MySQL data dictionary tables. (WL #12063)

  • Group Replication: The group communication engine (XCom) includes a cache for messages (and their metadata) that are exchanged between the group members as a part of the consensus protocol. Among other functions, the message cache is used for recovery by members that return to the group after a period where they were unable to communicate with the other group members.

    Previously, the size limit for the message cache was fixed at 1GB of memory, and the maximum number of messages in the cache was also fixed. Now that the group_replication_member_expel_timeout system variable (introduced in MySQL 8.0.13) can be set to allow up to an hour for members to return to the group rather than being expelled, having a fixed 1GB limit on the size of the cache could cause such nodes to be unable to recover the messages they missed on re-establishing communication.

    For this reason, beginning with this release, the XCom message cache has no fixed limit on the number of messages it can contain, and is bounded only by the limit set for the amount of memory it can use. The cache size limit can be set using the new group_replication_message_cache_size system variable, which has a default and minimum setting of 1GB, as used in previous MySQL Server versions. If the cache size limit is reached, XCom removes the oldest entries that have been decided and delivered. The cache size limit can be increased or reduced dynamically at runtime. If you reduce the cache size limit, XCom removes the oldest entries that have been decided and delivered until the current size is below the limit. The Group Replication Group Communication System (GCS) issues a warning when a message likely to be needed for recovery by a currently unreachable member is removed from the message cache. (Bug #26482507, WL #11615)

  • Group Replication: Large messages sent between Group Replication group members can now be split into multiple messages when they exceed a user-defined threshold size. Sending an abnormally large message can result in some group members being reported as failed and expelled from the group. This is because the single thread used by the group communication engine (XCom) is occupied processing the message for too long, so some of the group members might report the receiver as failed.

    A new system variable group_replication_communication_max_message_size specifies the maximum message size for Group Replication communications. Messages greater than this size are automatically split into fragments that are sent separately and reassembled by the recipients. Message delivery for a fragmented message is considered complete when all the fragments of the message have been received and reassembled by all the group members. Fragmentation is applied by default, and can be switched off by specifying a zero value for the system variable.

    Because older MySQL Server releases do not support message fragmentation, in order to ensure backward compatibility, Group Replication now has the concept of a communication protocol for the group. The communication protocol version is set to accommodate the oldest MySQL Server version that you want the group to support. A MySQL server at version X can only join and reach ONLINE status in a replication group if the group's communication protocol version is less than or equal to X.

    You can inspect the communication protocol in use by a group by using the new group_replication_get_communication_protocol() function, which returns the oldest MySQL Server version that the group supports. When a new member joins a replication group, it checks the communication protocol version that is announced by the existing members of the group. If the joining member supports that version, it joins the group and uses the communication protocol that the group has announced, even if the member supports additional communication capabilities. If the joining member does not support the communication protocol version, it is expelled from the group.

    If you need to change the communication protocol version of a group so that members at earlier releases can join, use the new group_replication_set_communication_protocol() function to specify the MySQL Server version of the oldest member that you want to allow. This makes the group fall back to a compatible communication protocol version if possible. If you upgrade all the members of a replication group to a new MySQL Server release, the group's communication protocol version is not automatically upgraded to match. If you no longer need to support members from earlier releases, use the group_replication_set_communication_protocol() function to set the communication protocol version to the new MySQL Server version to which you have upgraded the members. (Bug #26438884, Bug #23240361, Bug #28474580, Bug #91830, Bug #28642504, Bug #26941977, Bug #29240931, WL #11610)

  • Group Replication: A new system variable group_replication_autorejoin_tries lets you specify the number of tries that a member makes to automatically rejoin the group if it is expelled, or if it is unable to contact a majority of the group before the group_replication_unreachable_majority_timeout setting is reached. 0, the default, means that the member does not try to rejoin, and proceeds to the action specified by the group_replication_exit_state_action system variable.

    Activate auto-rejoin if you can tolerate the possibility of stale reads and want to minimize the need for manual intervention, especially where transient network issues fairly often result in the expulsion of members. If you specify a number of tries, when the member's expulsion or unreachable majority timeout is reached, it makes an attempt to rejoin (using the current plugin option values), then continues to make further auto-rejoin attempts up to the specified number of tries. After an unsuccessful auto-rejoin attempt, the member waits 5 minutes before the next try. During the auto-rejoin procedure, the member remains in super read only mode and displays an ERROR state on its view of the replication group. The member can be stopped manually at any time by using a STOP GROUP_REPLICATION statement or shutting down the server. If the specified number of tries is exhausted without the member rejoining or being stopped, the member proceeds to the action specified by group_replication_exit_state_action. (Bug #25673350, Bug #84784, Bug #28732174, WL #11284)

  • Group Replication: The default for group_replication_exit_state_action has been changed from ABORT_SERVER to READ_ONLY. (WL #12659)

  • Some InnoDB memory allocation functions that previously were evaluated at runtime now are evaluated at compile time, resulting in performance improvements. (Bug #29370811, Bug #94380)

  • The semijoin optimizations for IN subqueries have been extended to work with EXISTS subqueries as well; these can now be handled with the same semijoin strategies as IN subqueries, including first-match, materialization, duplicate weedout and loose index scan.

    In addition, the optimizer decorrelates trivially-correlated equality predicates in the WHERE condition attached to the subquery, so that they can be treated similarly to expressions in IN subqueries. The decorrelation is now also performed for IN subqueries as well as EXISTS subqueries.

    All hints and optimizer switches applicable to IN subqueries which are transformed into semijoin operations are also applicable to transformed EXISTS subqueries. All limitations on such optimization of IN subqueries also apply to transformed EXISTS subqueries, so that, for example, aggregate EXISTS subqueries cannot be transformed.

    For more information, see Optimizing IN and EXISTS Subquery Predicates with Semijoin Transformations. (Bug #28805105, Bug #28857990, WL #4389)

  • For consistency with the SQL standard and other RDBMS, table aliases are now supported in single-table as well as multi-table DELETE statements. (Bug #27455809)

  • WHERE conditions making comparisons between constants and column values in which the constant value is out of range or of the wrong type with respect to the column type are now handled during optimization rather than during execution. For example, given a table t with a column c whose type is TINYINT UNSIGNED, the condition in the query SELECT * FROM t WHERE c < 256 can be folded to SELECT * FROM t WHERE TRUE because 256 is out of range for a column of this type. Comparisons with NULL columns can also be optimized; if the column c is nullable, the same query can be optimized as SELECT * FROM t WHERE c IS NOT NULL.

    The comparisons that can be treated in this manner are >, >=, <, <=, =, <>/!=, and <=>. (BETWEEN and IN are not currently supported.) Types for which comparisons can be folded based on range and type include integer, floating-point, and fixed-point numeric types. BIT is not supported by this optimization, nor are columns of date and time types.

    For more information, see Constant-Folding Optimization. (Bug #90100, Bug #25484743, Bug #29048682, Bug #27703371, WL #11935)

    References: See also: Bug #28172538, Bug #29699347.

  • Added an experimental tree format for EXPLAIN output, which prints the generated iterator tree, and is intended to help users understand how execution was actually set up. EXPLAIN FORMAT=TREE is currently unsupported in production and both its syntax and output are subject to change in subsequent versions of MySQL. (WL #12074)

  • When binary log and relay log encryption is in use on a MySQL server (binlog_encryption=ON), you can now rotate the binary log master key at any time while the server is running by issuing ALTER INSTANCE ROTATE BINLOG MASTER KEY. You can do this on a regular basis to comply with your organization's security policy, and also if you suspect that the current or any of the previous binary log master keys might have been compromised.

    When you rotate the binary log master key, the new master key is used to encrypt the file passwords for the new binary log and relay log files, and subsequent files until the key is changed again. The file passwords for existing encrypted binary log files and relay log files on the server are also re-encrypted in turn using the new binary log master key, starting with the most recent files. Any unencrypted files are skipped. Finally, all binary log encryption keys that no longer apply to any retained binary log files or relay log files are cleaned up from the keyring. (WL #12080)

  • Table encryption can now be managed globally by defining and enforcing encryption defaults. The default_table_encryption variable defines an encryption default for newly created schemas and general tablespaces. The encryption default for a schema can also be defined using the DEFAULT ENCRYPTION clause when creating a schema. By default, a table inherits the encryption of the schema or general tablespace it is created in.

    Encryption defaults are enforced by enabling the table_encryption_privilege_check variable. The privilege check occurs when creating or altering a schema or general tablespace with an encryption setting that differs from the default_table_encryption setting, or when creating or altering a table with an encryption setting that differs from the default schema encryption.

    The TABLE_ENCRYPTION_ADMIN privilege permits overriding default encryption settings when table_encryption_privilege_check is enabled.

    For more information, see Defining an Encryption Default for Schemas and General Tablespaces. (WL #12261)

  • When insertions, deletions, or updates are made to partitioned tables, the binary log now records information about the partition and (if any) the subpartition in which the row event took place. A new row event is created for a modification that takes place in a different partition or subpartition, even if the table involved is the same. So if a transaction involves three partitions or subpartitions, three row events are generated. For an update event, the partition information is recorded for both the before image and the after image. The partition information is displayed if you specify the -v or --verbose option when viewing the binary log using mysqlbinlog. Partition information is only recorded when row-based logging is in use (binlog_format=ROW). (WL #12168)

Bugs Fixed

  • NDB Cluster: EXPLAIN of a query executed with table access type eq_ref could also show a condition being pushed down, even when condition pushdown was not supported for the query. Now the access type is checked before NDB checks the condition for a possible pushdown optimization.

    This fix does not affect handling of tables which are part of a pushed join, for which NDB continues to support pushed conditions as before. (Bug #27429615)

    References: See also: Bug #27397802, Bug #27808758, Bug #90301.

  • InnoDB: Undo tablespaces remained unencrypted after enabling undo tablespace encryption at startup. (Bug #29477795)

  • InnoDB: Problematic macros introduced with undo tablespace DDL support in MySQL 8.0.14 were revised. (Bug #29324132, Bug #94243)

  • InnoDB: Static thread local variables defined at the wrong scope were not released at thread exit. (Bug #29305186)

  • InnoDB: The performance_schema.data_locks LOCK_DATA column only showed the secondary index values of the locked record for a lock placed on a unique secondary index, which was not sufficient to ensure the uniqueness of identified records. The clustered index column values of the locked record are now appended. (Bug #29296645)

  • InnoDB: An incorrect count of transactions using a rollback segment for recovery of an XA transaction prevented an undo tablespace truncation operation from proceeding and left the purge thread busy checking for the undo tablespace to become empty. (Bug #29273194)

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

  • InnoDB: Invalid assertions were raised at startup after a failure to retrieve the space ID of a compressed file-per-table tablespace. The invalid assertion code was removed. (Bug #29221385, Bug #93760)

  • InnoDB: Optimized InnoDB internal temporary tables did not support in-place UPDATE operations, which caused the number of delete-marked records to increase continuously. The large number of delete-marked records could cause longer than expected query execution times. (Bug #29207450)

  • InnoDB: The std::sort function in the Contention-Aware Transaction Scheduling (CATS) algorithm was replaced by the std::stable_sort function to preserve the original FIFO order for transactions of equal weight. (Bug #29058967)

  • InnoDB: Write-ahead did not work as expected due to an incorrectly initialized variable.

    Thanks to Yuhui Wang for the contribution. (Bug #29028838, Bug #93442)

  • InnoDB: The base column information for a generated column was not stored. (Bug #29021730)

  • InnoDB: An implicit lock check on secondary indexes needlessly compared columns using collation rules. (Bug #29010725)

  • InnoDB: Assertion code related to the innodb_flush_method O_DIRECT_NO_FSYNC setting was no longer valid due to a recent modification to that setting. Assertion code was revised. (Bug #29007731)

    References: See also: Bug #27309336.

  • InnoDB: When starting the server with undo log encryption enabled, the master key for newly created undo tablespaces was generated without a server UUID. Undo tablespaces should use the DefaultMasterKey if the server UUID is not yet generated. (Bug #29006275)

  • InnoDB: Data dictionary code did not check for a returned data dictionary object, which could potentially cause the server to exit due to a null pointer access. (Bug #28977444, Bug #93362)

  • InnoDB: An undo tablespace file was left behind by a failed CREATE UNDO TABLESPACE operation. (Bug #28966457)

  • InnoDB: A CREATE UNDO TABLESPACE statement failed on Windows due to an invalid character in the file name. The failure resulted in a hang condition due to a missing OS_FILE_ON_ERROR_NO_EXIT attribute in the call that creates the undo tablespace file. (Bug #28955676)

  • InnoDB: Modifying the value of the innodb_undo_log_encrypt variable was not a blocking operation, which could lead to the modification being reverted by a background thread after the operation appeared to have been completed successfully. (Bug #28952870)

  • InnoDB: An invalid debug assertion was removed from the temptable::Handler::primary_key_is_clustered function. (Bug #28949332)

  • InnoDB: An ALTER TABLE ... EXCHANGE PARTITION operation did not properly update column table_id values in the data dictionary. (Bug #28927005)

  • InnoDB: Memory leaks discovered in the innochecksum utility were removed. (Bug #28917614, Bug #93164)

  • InnoDB: A DDL operation that followed a failed attempt to create an index on a virtual column resulted in an assertion failure. (Bug #28825718)

  • InnoDB: A performance regression was observed for partial update operations on compressed BLOBs less than or equal to 128KB in size. (Bug #28784301)

  • InnoDB: Running aggregated queries raised Valgrind warnings. (Bug #28711717)

  • InnoDB: A CHECK TABLE operation raised an assertion failure. A pointer to a local call stack variable was not set back to null before a function exit. (Bug #28525110)

  • InnoDB: DDL log functions were modified to handle ER_TOO_MANY_CONCURRENT_TRXS errors. (Bug #28523127, Bug #92071)

  • InnoDB: The purge thread failed to free LOB data pages. (Bug #28510599)

  • InnoDB: Some DDL log table transactions were not rolled back prior to DDL log recovery. (Bug #28494969)

  • InnoDB: A function invoked during SHOW CREATE TRIGGER processing that retrieves the table name did not perform the expected lowercase conversion. (Bug #28351038)

  • InnoDB: The INFORMATION_SCHEMA.INNODB_FOREIGN TYPE column reported incorrect values. (Bug #28315651, Bug #91577)

  • InnoDB: A Linux AIO handler function failed to check if completed I/O events succeeded. Thanks to Wei Zhao for the contribution. (Bug #27850600, Bug #90402)

  • InnoDB: An assertion failure was raised in a check that determines if a transaction holds an implicit lock on a secondary index. A transaction that does not change the columns of a secondary index that includes virtual columns could be incorrectly determined to hold an implicit lock. (Bug #27491839)

  • InnoDB: A function called by a CREATE TABLE thread attempted to access a table object after it was freed by a background thread.

    Thanks to Yan Huang for the patch. (Bug #27373959, Bug #89126)

  • InnoDB: Two sessions concurrently executing an INSERT ... ON DUPLICATE KEY UPDATE operation generated a deadlock. During partial rollback of a tuple, another session could update it. The fix for this bug reverts fixes for Bug #11758237, Bug #17604730, and Bug #20040791. (Bug #25966845)

  • InnoDB: When the method used to access a joined table was const, InnoDB attempted to unlock the matching row multiple times. (Bug #20939184)

  • InnoDB: The INDEX_LENGTH value in INFORMATION_SCHEMA.TABLES was not updated when adding an index. (Bug #19811005)

  • Partitioning: Some partitioning DDL statements were improperly rejected due to name validation checks which used the wrong table identifier. (Bug #29317007)

  • Partitioning: While rolling back ALTER TABLE ... COALESCE PARTITION, the server sometimes attempted to lock and close partitions which had been dropped as a result of this statement. (Bug #28517446)

  • Partitioning: An AUTO_INCREMENT key added to a partitioned table by an ALTER TABLE statement using ALGORITHM=INPLACE restarted on each partition. (Bug #92241, Bug #28573894)

  • Replication: If the WAIT_FOR_EXECUTED_GTID_SET() function was used with a timeout value including a fractional part (for example, 1.5), an error in the casting logic meant that the timeout was rounded down to the nearest whole second, and to zero for values less than 1 second (for example, 0.1). The casting logic has now been corrected so that the timeout value is applied as originally specified with no rounding. Thanks to Dirkjan Bussink for the contribution. (Bug #29324564, Bug #94247)

  • Replication: The consistency level AFTER for the system variable group_replication_consistency did not include the consistency guarantees provided by BEFORE_ON_PRIMARY_FAILOVER. These consistency guarantees, which were already implicitly present with the BEFORE and BEFORE_AND_AFTER consistency levels, are now provided with AFTER. (Bug #29315752, Bug #94213)

  • Replication: On Debian-based platforms (such as Ubuntu), if the hostname resolved to 127.0.1.1 - which is the default on these platforms - it was not possible to create a cluster using the default settings. Now, in such situations a proper validation of the instance is performed before creating a cluster and adding instances to it. (Bug #29246110)

  • Replication: In a blocked group, if you set an invalid value for group_replication_force_members and then issued STOP GROUP_REPLICATION, the server could stop unexpectedly. (Bug #29119961)

  • Replication: MySQL Server's behavior when the mysql.gtid_executed table cannot be accessed has been refactored to provide appropriate error responses and actions. The MySQL server now ensures that writes are permitted to the mysql.gtid_executed table when the server is in read only or super read only mode, so that the binary log file can still be rotated in these modes. If the mysql.gtid_executed table cannot be accessed for writes, and the binary log file is rotated for any reason other than reaching the maximum file size (max_binlog_size), the current binary log file continues to be used. An error message is returned to the client that requested the rotation, and a warning is logged on the server. If the mysql.gtid_executed table cannot be accessed for writes and max_binlog_size is reached, the server responds according to its binlog_error_action setting. If IGNORE_ERROR is set, an error is logged on the server and binary logging is halted, or if ABORT_SERVER is set, the server shuts down. (Bug #29111514)

  • Replication: When issuing STOP GROUP_REPLICATION while the member was trying to assess whether or not it had lost majority, the server could stop unexpectedly. (Bug #29053128)

  • Replication: When a RESET MASTER TO statement is used to specify the starting index number for binary log files, the maximum number that you can specify has been reduced from the maximum integer value to 2000000000. If the maximum integer value was specified, the server was not able to start up because no further binary log files could be created. The server also previously experienced a segmentation fault in that situation. (Bug #28980788, Bug #28995220)

  • Replication: On a replication slave with GTIDs in use and binary logging disabled, an assertion was raised in debug mode when a DDL statement was filtered out by a table filter. (Bug #28965972)

  • Replication: Two issues with the deserialization of statement based replication events in the binary log were corrected. (Bug #28889181, Bug #29028491)

  • Replication: If an applier thread was stopped while it was in the process of opening a table, no error was set, which could result in a segmentation fault or assertion depending on the build type. Error handling is now correctly activated in this situation. (Bug #28864557)

  • Replication: With GTIDs in use on the server, the master info log on a replication slave was being synchronized every time the master skipped a transaction using the auto-skip function. The process ends with a dummy heartbeat which is sent to the slave and caused a forced flush to the log, and this could have a large cumulative impact on the write load on the slave. The same issue could occur in a circular replication topology with events that originated from the same server and were therefore ignored, which were also handled by the slave with a forced flush to the log. The slave handling code has now been changed to remove the forced flush for heartbeat events and for ignored events received through circular replication, so that the master info log is only synchronized when appropriate (for example, when a CHANGE MASTER statement is issued, or the binary log is rotated). (Bug #28815555, Bug #85158)

  • Replication: When an ALTER TABLE statement is used with a DEFAULT clause to specify an expression default value for a new column, and the expression default value refers to a nondeterministic function, the statement is unsafe for statement-based replication. Previously, such statements were also evaluated in terms of GTID consistency, which was not the appropriate check as the statements do not impact GTID consistency. Now, these statements are evaluated only for binary logging and are handled depending on the binary logging format in use. When binlog_format is set to STATEMENT, the statement is logged but a warning message is written to the error log. When binlog_format is set to MIXED or ROW, the statement is not executed and an error message is written to the error log. (Bug #28799939)

  • Replication: In a replication group configured in single-primary mode (group_replication_single_primary_mode=ON, which is the default), if severe network delays affected the group, it was possible for the primary and the secondaries to reach different decisions on a transaction, which could lead to divergence in the gtid_executed sets on the members. The issue has now been fixed. (Bug #28768550, Bug #28966455, Bug #92690)

  • Replication: When you use the group_replication_force_members system variable to force a new configuration for a group, the group communication engine (XCom) now checks that you have not included any group members that are currently unreachable. If any are found, the reconfiguration is disallowed and an error is returned. (Bug #28678845)

  • Replication: GRANT statements that were written to the binary log were logged incorrectly in some cases, which could result in a GRANT statement that executed successfully on the master causing an error on the replication slave. (Bug #28643405, Bug #29155451, Bug #93750)

  • Replication: If a storage engine has the capability to log in STATEMENT format but not in ROW format, when binlog_format is set to STATEMENT, an unsafe SQL statement should be logged and a warning message should be written to the error log. However, such statements were instead not executed and an error message was written to the error log, which is the correct behavior when binlog_format is set to MIXED or ROW. The issue has now been corrected so that unsafe statements are logged with a warning as expected when binlog_format is set to STATEMENT. (Bug #28429993, Bug #73936)

  • Replication: It is possible for a replication group member to go offline briefly, then attempt to rejoin the replication group again before the group has detected its failure and been reconfigured to remove the member. Previously, in this situation, the rejoining member could participate in XCom's consensus protocol if it received and processed messages intended for its pre-crash incarnation. This could cause XCom to deliver different values for the same consensus round, because the rejoining member could make a different decision before and after failure. To prevent this situation, a rejoining member now ignores messages intended for its pre-crash incarnation. (Bug #27383487)

  • Replication: On overloaded servers there was a possibility that when a member joined the group, the VIEW_CHANGE_LOG_EVENT event which marks that point was not logged in the correct place. This could lead to errors in the data transfer to the newly joining server and data divergence. Now, the VIEW_CHANGE_LOG_EVENT event is logged in the correct place in the binary log. In addition, warnings are logged about the delay in logging the event. (Bug #93347, Bug #28971594)

  • Replication: When a member joined a group on server start, if the join process failed, for example because the server was incompatible with the group, there was a possibility that the offline member could still see another member as being online. Now, in such a situation the information shown in the performance_schema.replication_group_members table is restricted to the local member when it is OFFLINE. (Bug #92110, Bug #28533993)

  • Replication: In the event of the recovery channel failing, unprocessed relay logs were being erased. (Bug #90671, Bug #27940732)

  • Group Replication: START GROUP REPLICATION did not function properly when the port specified for the member's local address was busy. (Bug #29347285)

  • Group Replication: When a host name was specified in the IP address whitelist for Group Replication (group_replication_ip_whitelist),IPv6 addresses were used for name resolution and whitelist comparison when an IPv4 address was also available. An IPv4 address should always be preferred for Group Replication connections. Now, if the host name resolves to an IPv4 address, any IPv6 addresses are not considered for comparison to the whitelist. (Bug #28841543)

  • Group Replication: Previously, relay logs could not be rotated manually for the Group Replication group_replication_applier channel using the FLUSH RELAY LOGS statement. Due to this restriction, when encryption was enabled for binary log files and relay log files (binlog_encryption=ON), as available beginning with MySQL 8.0.14, the relay log file in use on that channel could not be rotated immediately if encryption was disabled again. The restriction had a similar impact on binary log master key rotation, as available from MySQL 8.0.16. The restriction has now been removed, and the FLUSH RELAY LOGS statement and corresponding internal requests now operate on the group_replication_applier channel as for any other channel, with the exception that if the request is received while a transaction is being applied, the request is performed after the transaction ends. The requester must wait while the transaction is completed and the rotation takes place. This behavior prevents transactions from being split, which is not permitted for Group Replication. (Bug #28684376)

  • Group Replication: A replication group member could trigger a local view after being expelled from the group due to a loss of majority. This resulted in a message incorrectly stating that the member had resumed regular operation after the expulsion. Group Replication now checks before delivering a local view that the member has not been expelled. (Bug #27349236)

  • Group Replication: If an invalid value was specified for group_replication_communication_debug_options, the Group Communication System set its corresponding internal variable to GCS_DEBUG_NONE, and the server returned the invalid value for a SHOW VARIABLES query. The value of this system variable is now checked during server initialization, and if an invalid value was specified, an error message is logged and Group Replication does not start automatically. (Bug #26729404)

  • macOS: CMake 3.12.4 or higher (which forces UseModernBuildSystem = NO) is now required on macOS if building with Xcode rather than Makefiles. (Bug #28893131)

  • Microsoft Windows: Validity testing for the named_pipe_full_access_group system variable did not account for NULL values. (Bug #29256690)

  • Microsoft Windows: When multiple instances of mysqld were started with the --no-monitor option on the same host for same user, the SHUTDOWN command shut down the wrong server process. This fix creates a unique shutdown event name for use with --no-monitor by appending the process ID of the process. (Bug #28723675)

  • JSON: The JSON path parser now propagates errors in the same way as most other components of the MySQL server, returning true on error and false on success. (Bug #28851426)

  • JSON: Removed an unneeded type lookup in Json_wrapper::get_datetime(). (Bug #28851324)

  • The authentication_ldap_simple plugin could enforce authentication incorrectly. (Bug #29637712)

  • RPM package obsoletes were updated to enable successful upgrades from MariaDB to MySQL on EL8. (Bug #29413354)

  • It was possible for the result of an outer join to contain a non-NULL row where a NULL extended row was expected. (Bug #29402481)

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

  • SET PASSWORD FOR ... could not be executed as a prepared statement. (Bug #29387041, Bug #94416)

  • Builds under Visual Studio could fail while building MySQL Router libraries. (Bug #29382197)

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

  • Imported foreign keys did not work if defined before the referenced table. (Bug #29379078, Bug #94400)

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

  • When an error was raised while evaluating the ESCAPE clause of a LIKE expression at resolve time, the error status was not propagated to the caller. (Bug #29368521)

  • Tablespace files for the innodb_table_stats_backup and innodb_index_stats_backup metadata backup tables were not removed after an in-place upgrade from MySQL 5.7 to MySQL 8.0. (Bug #29365552)

  • While flattening a subquery, if a predicate which was always false was present, the MySQL Optimizer did not perform any kind of transformation, resulting in a subquery that was not prepared, and which asserted later when it was executed. To resolve this issue, when such a predicate is present in a subquery, the subquery's query expression is now unlinked from the query block. (Bug #29356132)

  • Upgrade from MySQL 8.0.11, 8.0.12, or 8.0.13 to MySQL 8.0.14 or 8.0.15 failed if an event, routine, or trigger was defined with the ALLOW_INVALID_DATES SQL mode. The SQL mode identifier in the data dictionary was changed in MySQL 8.0.14, causing a migration failure. (Bug #29350955)

  • RPM builds ignored the WITH_SSL configuration setting. (Bug #29347534)

  • Length metadata for the TO_SECONDS() function was not always calculated correctly. (Bug #29321387)

  • Conditions using windowing functions removed due to being always true or false were not always handled correctly. (Bug #29320484)

  • SET ROLE statements could leak memory. (Bug #29304583)

  • Upgrading from MySQL 5.7 to MySQL 8.0 on Windows failed with Error 197 from SE while migrating tablespaces. The error was due to an access share violation that occurred when attempting to open a tablespace file. (Bug #29292860)

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

  • The COMPILATION_COMMENT_SERVER value could be incorrect in RPM packages. (Bug #29284651)

  • CREATE TABLE IF NOT EXISTS failed even if the table already exists if the new table definition had no primary key and the sql_require_primary_key system variable was enabled. (Bug #29283055, Bug #94134)

  • A delete from a partitioned table from which all partitions had been pruned away was not always handled correctly. (Bug #29280186)

  • The CMake check for the GNU gold linker could fail with Clang. (Bug #29278244)

  • The data dictionary version was incremented for the MySQL 8.0.16 release. (Bug #29278241)

  • An argument of the wrong type to a function used with DISTINCT was not always handled correctly. (Bug #29277571)

  • Length metadata for the QUOTE() function was not always calculated correctly. (Bug #29276074)

  • When evaluating GREATEST() or LEAST(), MySQL checked for correct signedness of the return value before checking it for NULL. (Bug #29275835)

  • When strict SQL mode was not in effect, the values of some string functions returning NULL to indicate a result greater than max_allowed_packet were handled inconsistently behaviour, which could result in incorrectly sorted output and possibly other misbehaviors. (Bug #29272683)

    References: See also: Bug #97301, Bug #29133127.

  • Logic that checks if upgrade is supported to a particular server version was inverted to check for server versions from which upgrade is not supported. (Bug #29270297)

  • Event creation could store an incorrect repetition interval. (Bug #29269819, Bug #94085)

  • A WHERE condition containing a view reference or an item created by a transformation was not always handled correctly. (Bug #29268867, Bug #29268698, Bug #28723669, Bug #29244238)

  • mysql_ssl_rsa_setup failed to compile using GCC 9. (Bug #29245251)

  • If CMake finds a libtirpc library that is too old to work with MySQL, it tries to use Sun RPC from glibc instead. (Bug #29240701)

  • The server could fail to write slow queries to the slow query log due to incorrect calculation of query execution time. (Bug #29232684, Bug #93963)

  • MySQL regular expression functions using positions employed internal indexes based on 16-bit chunks, rather than on codepoint positions. (Bug #29231490)

  • On Windows, the MySQL MSI installer could fail to correctly detect whether the Visual Studio 2015 Redistributable was installed. (Bug #29227209)

  • SDI JSON files did not include the m_hidden field of Index_impl objects. This made it hard to use the SDI JSON to recreate the CREATE statement for the table because InnoDB adds a number of hidden indexes. The SDI JSON now includes the m_hidden field. This changes SDI format, so the SDI version number was increased to the current server version number. (Bug #29210646, Bug #93914)

  • The position hint for the last row in a range frame was updated to be one row past the actual last row in the frame. (Bug #29201831)

  • In a column definition, multiple constraint definitions were not accepted when the first was a CHECK constraint. (Bug #29191994)

  • Error log information buffered during startup could be buffered too long if the server was performing an upgrade. (Bug #29189532)

  • For nullable columns, if we find an expression that is always true except when the column is NULL, the expression is folded to column IS NOT NULL. When such an expression was nested, this caused NULL rows to be selected in error. To prevent this from happening, such an expressions when nested is now instead folded to IF(column IS NULL, NULL, TRUE). (Bug #29179604)

  • PERIOD_ADD() did not handle values greater than 32 bits in length for the period argument correctly on Windows platforms. (Bug #29175262)

  • When sql_auto_is_null is enabled, a WHERE clause of the form WHERE auto_increment_col IS NULL is rewritten as WHERE auto_increment_col = LAST_INSERT_ID(). This transformation was only performed once per auto-incremented value, which made it difficult to know in advance whether the transformation would be performed. Now the transformation is performed unconditionally whenever sql_auto_is_null is enabled.

    In addition, the value returned by LAST_INSERT_ID() is now treated as unsigned, fixing a failure to match an auto-incremented value outside the range of a signed BIGINT. (Bug #29171668)

  • On Debian and Ubuntu, installation operations in noninteractive mode ignored the root password, resulting in the auth_socket authentication plugin being installed by default. (Bug #29165407)

  • The harness_plugin_eventlog declaration caused compilation errors in some build environments. (Bug #29160214)

  • The logic for truncating or extending a decimal constant to the desired number of fractional digits during constant folding was lacking. Extra trailing zeros in the fraction could trigger an attempt to widen the faction, since the decision to widen was based on the number of non-zero fractional digits, rather than on total number of fractional digits, leading to an assert (in debug builds) in the internal function widen_fraction(). This issue is fixed by identifying where it is possible merely to truncate excess trailing zeroes. In this case, it is not necessary to adjust the comparison operator, and the constant can be replaced by one having fewer trailing zeroes instead. (Bug #29155439)

  • On Windows, the internal function get_mysql_time_from_str_no_warn() did not always perform proper error checking. (Bug #29155126)

    References: See also: Bug #29175262.

  • Under certain conditions, RENAME TABLE statements that renamed the same table multiple times could raise an assertion or cause a server exit. (Bug #29140407)

  • For debug builds, starting the server with --event-scheduler=DISABLED could result in an assertion being raised for certain events. (Bug #29140298, Bug #93719)

  • In debug builds, When strict SQL mode was not in effect, the CONCAT() and CONCAT_WS() functions raised an assertion if the result was longer than max_allowed_packet. (Bug #29133127)

  • An out-of-range fractional part could produce incorrect timestamps in SET SESSION timestamp statements. (Bug #29120569, Bug #93600)

  • The mysql_service_component_sys_variable service could access component system variables but not server or plugin system variables. (Bug #29113463)

  • ALTER TABLE ... CONVERT TO CHARACTER SET could produce a memory-access error. (Bug #29058369, Bug #93603)

  • The mysql.tablespaces.name column limit was 259 bytes, which was less than required for permitted identifier lengths. The column limit was raised to 268 bytes. (Bug #29053560, Bug #93587)

  • For debug builds, for spatial computations that raised an assertion, partition-handling code ignored the error, resulting in a server exit. (Bug #29047811)

  • A zero length LOB that was stored externally caused an assertion failure. (Bug #29047795)

  • Handling of the COMPILE_DEFINITIONS and COMPILE_FLAGS CMake options was adjusted to avoid cross-compiling failures. (Bug #29041100)

  • The server could try to read the first diagnostics area message even when the max_error_count system variable was set to zero, resulting in a memory-access error. (Bug #29031684)

  • When comparing DATE values with constant strings, MySQL first tries to convert the string to a DATE and then to perform the comparison. When the conversion failed, MySQL executed the comparison treating the DATE as a string, which could lead to unpredictable behavior. Now in such cases, if the conversion of the string to a DATE fails, the comparison fails with ER_WRONG_VALUE. (Bug #29025656)

    References: See also: Bug #95466, Bug #29812087.

  • With the --users option, mysqlpump wrote CREATE USER and GRANT statements to the output, but too late to apply to the other objects created by the dump. Consequently, restoring the dump file created the user accounts too late to apply to other objects created by the file. mysqlpump now writes user accounts to the dump file before other objects. (Bug #29023216)

  • For syntax errors at the position of the WITH keyword, the parser error message identified the problem at the incorrect location. (Bug #29022263)

  • MySQL builds using recent versions of the International Components for Unicode (ICU) now return ER_REGEXP_ILLEGAL_ARGUMENT rather than the generic error ER_REGEXP_ERROR for malformed regular expressions. (Bug #29016798)

  • On Windows, the LDAP library could not be found if the file system was case sensitive. (Bug #29016220)

  • Values selected from the TABLE_COMMENT column of the INFORMATION_SCHEMA.TABLES table could be truncated. (Bug #29014272, Bug #93451)

  • Data layer memory leaks related to unfreed schemas were discovered in ASAN and Valgrind builds. (Bug #29008688)

  • A GROUP BY query with ROLLUP incorrectly raised ER_WRONG_FIELD_WITH_GROUP when used with an ORDER BY clause that contained an expression.

    The same issue also led to incorrect ordering of the result from a GROUP BY query with ROLLUP when ordering on a function. (Bug #29006668, Bug #29054096)

  • The parser accepted multiple COLLATE clauses in generated column definitions. It now accepts a single COLLATE clause. (Bug #28997518)

  • INSERT ... ON DUPLICATE KEY UPDATE could perform incorrect updates. (Bug #28995498, Bug #93410)

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

  • A damaged mysql.user table could cause a server exit. (Bug #28986737)

  • Reading rows from the Performance Schema data_locks or data_lock_waits table could return an unbounded number of rows during a scan, resulting in a server exit due to excessive memory allocation. This situation now produces an error. (Bug #28977428, Bug #87748)

  • Calculating the cost of materialization for a LATERAL join on an empty table led to an assertion. Now in such cases, the query cost is reported as zero. (Bug #28976533)

  • For debug builds, an invalid utf8 character in the comment string for a column type in CREATE or ALTER DDL statements raised an assertion. (Bug #28972424, Bug #93321)

  • The CMake check for tirpc headers now falls back to using pkgconfig, to enable finding the headers on more Linux platforms. This requires that pkgconfig be installed. (Bug #28970313, Bug #93341, Bug #28997093)

  • mysqld could undergo an unplanned shutdown when a component in the WHERE clause of a subquery was non-deterministic, in this particular case due to referencing a user variable that was also set in the same statement. This issue is fixed by ignoring predicates having non-deterministic components.

    In addition, since non-deterministic subqueries as a general rule should be evaluated per outer row, these should not be targets for materialization strategy. This is prevented by not decorrelating the non-deterministic predicates. When possible, the same strategy selection for non-semijoin and non-deterministic subqueries is also now enforced. (Bug #28970261)

  • ALTER TABLE statements to change a table storage engine could hang when user-level locks and explicit table locks had been acquired earlier. (Bug #28966941)

  • COUNT() with LIMIT ... OFFSET returned a different result from that obtained with other aggregate functions used with this clause. (Bug #28961843)

  • Extracting the value of the MYSQL_HOME environment variable could change the value of the variable stored following MYSQL_HOME in the environment. (Bug #28960613)

  • Item_subselect::walk_body() now walks FROM clauses. (Bug #28955358)

  • An issue was uncovered in query plan for a query with the following two IN subqueries:

    • A subquery with a derived table containing an outer reference to the topmost query

    • A subquery with a derived table, which was not outer-correlated, was semijoined, and was not lateral.

    For the second subquery: calculation of the map of dependencies neglected to exclude irrelevant lateral tables, and wrongly included dependencies of the derived table in the first subquery. (Bug #28954838)

  • An error generated while evaluating a constant expression in certain GROUP BY queries was not checked for in a timely fashion. (Bug #28949452)

  • When comparing a DATE or DATETIME value with a string MySQL first tries to convert the string to the same type (DATE or DATETIME) and then to compare the two as values of that type. If this conversion fails, MySQL raises an Incorrect date value warning and then falls back to comparing the values as strings, which is the expected behavior. In some cases, even though the converted string did not reflect a valid DATE or DATETIME value, no warning was issued so and it was compared with the DATE or DATETIME value as a value of that type. Now in such cases, the converted string is always checked for validity as a DATE or DATETIME before being compared, unless the ALLOW_INVALID_DATES server SQL mode has been set explicitly. (Bug #28940878)

  • Long client host names could cause unexpected server behavior. (Bug #28936359)

  • Substitution of a large number of parameters in a single prepared statement could lead to excessive and unnecessary reallocation of memory. This is fixed by having String::replace() use exponential buffer growth as String::append() does. (Bug #28929977)

  • The data dictionary cache could become out of sync with data dictionary contents due to failure to check the result of a transaction-related operation. (Bug #28923782, Bug #93196)

  • Determination of the number of online CPUs available to the mysqld process is now more accurate. Thanks to Daniel Black for the contribution. (Bug #28907677, Bug #93144)

  • The INFORMATION_SCHEMA.TABLES TABLE_COMMENT column reported the wrong error message due to an invalid view. (Bug #28901919)

  • After upgrading, the INFORMATION_SCHEMA.TABLES view reported View 'view_name' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them for several sys schema views. The upgrade process did not update the referencing view state. (Bug #28901821)

  • Creating histograms for large tables (millions of rows) having many distinct column values took an excessive amount of time.

    The fix make this process marginally slower for data sets with few distinct values and consumes slightly more memory than previously, but for large data sets with many distinct values it is significantly faster. (Bug #28888936)

  • Upgrade from MySQL 5.7 to MySQL 8.0 failed for instances with a an InnoDB 4K page size due a key length error that should be suppressed during upgrade. (Bug #28884503)

  • An incorrectly configured keyring plugin could cause a server exit. (Bug #28876033)

  • Two issues were found in cases involving use of the COUNT() function:

    • When the argument passed to COUNT() was a nullable expression, it was possible for the function to return an incorrect result.

    • A query using COUNT() together with an EXISTS subquery returned an incorrect result.

    (Bug #28857990, Bug #29240516)

  • Commands for invoking ccache during MySQL builds were generated incorrectly. (Bug #28841612, Bug #92927)

  • Previously, for INSERT statements that listed insert column names multiple times, only the first duplicated name was reported. Now, all duplicated names are reported. (Bug #28836669)

  • When using ROLLUP, the GROUP BY may yield NULL in some rows. Expressions referencing any of these rows could lose the NULL, producing an incorrect result. (Bug #28836345)

  • After a failed attempt to open a table, attempts to discover the table from the storage engine did not check for an error return, which could cause the server to hang if an error occurred. (Bug #28828450)

  • The server could exit when trying to drop a user who had been granted a particular role. (Bug #28817441)

  • MySQL Router compilation failed if MySQL was configured with -DWITH_MYSQLX=0. (Bug #28811356)

  • A function called during data dictionary upgrade temporarily modified the avoid_temporal_upgrade parameter so that a check for old temporal types is always performed. Because multiple threads could call the function concurrently, a check was added to ensure that the parameter value could be safely modified during data dictionary upgrade. (Bug #28805429)

  • An EXISTS subquery is converted to a semijoin operation. The optimizer chooses a materialization lookup strategy for this semijoin, but because the subquery is not correlated with the outer query block, there were no keys to use for the lookup, which caused the parent query to fail. To solve this issue, we use two equal constant items as keys, to ensure that the materialized query gets the constant as a key (and so that the materialized table consists of at most one row). (Bug #28805105)

  • The Last_query_cost status variable now shows the cost of queries which contain multiple blocks such as subqueries or unions. (Previously, this variable was set only for simple queries consisting of a single query block.) (Bug #28786951)

  • The message displayed by mysqld when a fatal signal occurred has been simplified and made more informative. It also does not display the calculation of memory usage, which had become out of date and inaccurate. (Bug #28773322, Bug #92731)

  • The skip_name_resolve system variable could be persisted using SET PERSIST_ONLY to enable it, but not to disable it. (Bug #28749668)

  • Removed obsolete and unnecessary condition pushdown handling in iterators except where required by single table update and delete queries. (Bug #28745859)

  • IS NOT NULL predicates are added as part of early filtering of NULL for ref access performed by the Optimizer. For queries having a star-join topology, redundant duplicates of these predicates were added, which made evaluation of affected WHERE conditions less efficient. (Bug #28727717)

  • CMake could generate an incorrect order of system includes when MySQL was configured to use the bundled version of a system library. (Bug #28727631, Bug #92615)

  • Some numeric operations involving double to long long conversions could return different results on Windows and Linux. (Bug #28706832)

  • An attempt to access a null pointer could occur during prepared statement execution. (Bug #28692136)

  • FROM_UNIXTIME() returned an out-of-range value if passed an argument that, when rounded up, exceeded the epoch value. Now it returns NULL as for other out-of-range values. (Bug #28671811, Bug #92501)

  • A replicated DDL operation could result in a 'duplicate entry on primary key' error during recovery on servers started with the slave_parallel_workers system variable. (Bug #28670843)

  • Empty host names in accounts could cause the server to misbehave. (Bug #28653104)

  • The MySQL 5.7 to MySQL 8.0 upgrade process did not check for the existence of tablespace files, which could result in an inconsistent data dictionary. (Bug #28642608)

  • Type casting of ENUM behaved differently in subqueries than not in subqueries. (Bug #28547906, Bug #92173)

  • Statements that caused truncation of floating-point values could be executed as prepared statements even when the server SQL mode included STRICT_TRANS_TABLES. In addition, if the binary logging mode was MIXED, such statements were propagated to the slave, where they caused errors. (Bug #28546855)

  • Reducing the value of thread_cache_size at runtime did not reduce the size of the thread cache. (Bug #28508923, Bug #92024)

  • Some error messages still referred to the PASSWORD() function, which has been removed. (Bug #28498714)

  • The Aborted_connects status variable was not incremented for unsuccessful connection attempts, if connections were managed by the thread_pool plugin. (Bug #28490126)

  • mysqladmin shutdown did not wait for mysqld to shut down. (Bug #28466137, Bug #91803)

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

  • Specifying CURRENT_USER as the user in GRANT statements could fail. (Bug #28454014)

  • Repeated invocations of stored procedures which executed queries undergoing short-circuit evaluation were not always handled correctly. (Bug #28379655)

  • Keyring migration should require only read access to the source keyring, but failed unless the user had write access. (Bug #28339014)

  • If a user performing a keyring migration did not have write access to the keyring file, the migration failed but reported success in its final error log message. (Bug #28330922)

  • During FLUSH STATUS execution, the Performance Schema unnecessarily aggregated session status to global status, causing double counts for some status variables. (Bug #28291258, Bug #91541)

  • mysql_secure_installation no longer attempts to read a password from the .mysql_secret file. This was created by mysql_install_db, a program that has been removed. (Bug #28235716, Bug #91270)

  • Some status variable values could temporarily increase before returning to their original value. (Bug #27839644, Bug #90351)

  • Client programs did not exit if --ssl-fips-mode was given but FIPS mode could not be set to the specified option value. (Bug #27809371)

  • Executing ALTER INSTANCE ROTATE INNODB MASTER KEY and migrating keys from the keyring_file plugin to the keyring_encrypted_file plugin could make encrypted tables unusable. (Bug #27760952)

  • When upgrading from MySQL Community to Commercial, the root password prompt was shown even when the data directory existed. (Bug #27741998)

  • In the client/server protocol, malformed packets for prepared statements could go undetected and cause an assertion to be raised. (Bug #27627731)

  • Changes were made in session connect and disconnect handling for threads in order to speed up query throughput when using the X Plugin. Previously, a session (Srv_session) was attached to and detached from the current thread with every command; now, this thread switch takes place only when disconnecting the current session, or when the current thread and the thread being attached to belong to different plugins. (Bug #27463277)

  • The PERSIST and PERSIST_ONLY keywords were reserved by mistake. They are now nonreserved keywords. (Bug #25220656)

  • Installing and uninstalling a plugin concurrently with client connection activity could cause a server exit. (Bug #22980441)

  • The LOAD_FILE() function could fail for files for which stat() should be considered only advisory, such as files under /proc. (Bug #18394503, Bug #72027)

  • A query using an ORDER BY clause failed silently when the table being queried had an implicit full-text index and the sort buffer was of insufficient size to contain the sorted keys. (Bug #93241, Bug #28940361)

  • A loadable function returning a string value now sets an explicit return type. Depending on the arguments passed to the function, this is one of VARCHAR, MEDIUMBLOB, or LONGBLOB. (Bug #92890, Bug #28828169)

  • Made a comparison in the internal method Item_result::item_cmp_type() more efficient. Our thanks to Daniel Black for the contribution. (Bug #92784, Bug #28796107)

  • A windowing function employed in an arithmetic expression produced an incorrect result when the query containing it used DISTINCT. (Bug #92503, Bug #28672483)

  • Some queries involving complex joins leaked file handles. (Bug #90902, Bug #28039829)

  • Fedora packaging now supports Fedora 30.

  • Ubuntu 14.04 and SLES 11 are EOL, and no longer supported.