MySQL 8.0.11

What's new in this version:

Bugs Fixed:
- Important Change: When NO_ZERO_DATE SQL mode is enabled, ALTER TABLE rejects attempts to add DATE or DATETIME columns that are declared NOT NULL to a nonempty table if no DEFAULT is specified for that column. Since a generated column has no default value, this restriction also prevented addition of a generated DATE NOT NULL or DATETIME NOT NULL column to a nonempty table. Since the expression used to generate the column can be used in place of the missing default for determining the column value, this restriction is now lifted for generated columns.
- Important Change: For ANALYZE TABLE ... UPDATE HISTOGRAM statements, the WITH N BUCKETS clause is now optional. If not specified, the default value for BUCKETS is 100.
- InnoDB: The server was stopped before a fatal error message was written to the error log.
- InnoDB: When determining if a wait lock could be granted, locks held by victim transactions that were being rolled back were ignored.
- InnoDB: An error occurred in Sdi_Decompressor::decompress() when compiling a debug build using GCC 7.2.0.
- InnoDB: An assertion was raised when registering buffer pool chunks during parallel creation of multiple buffer pools. A mutex is now used to protect registration of buffer pool chunks in the buffer pool chunk map.
- InnoDB: Enabling the standard monitor caused an error.
- InnoDB: An internal field used to mark a column as hidden was changed from a boolean field to an enum field to support additional levels of column visibility.
- InnoDB: An invalid zlib-related Valgrind failure reported that a conditional jump or move depends on uninitialized value.
- InnoDB: An incorrect GROUP BY result was returned when using the TempTable storage engine and a NO PAD collation.
- InnoDB: An incorrect compression length value in a page compression function caused hole punching to be skipped the first time pages are compressed.
- InnoDB: Starting the server with an incorrect --log-bin option value raised an assertion, and subsequent attempts to start the server with a correct --log-bin value or without the --log-bin option continued to produce assertion failures.
- InnoDB: A large object (LOB) reference was not updated when a LOB was inserted during an UPDATE operation.
- InnoDB: After restarting the server, a TRUNCATE TABLE operation raised an assertion due to table flags that were inconsistent with remote data directory information stored in memory.
- InnoDB: Attempting to create a temporary table in a file-per-table tablespace using CREATE TEMPORARY TABLE ... TABLESPACE syntax failed to report an error. Temporary tablespaces are only permitted in the temporary tablespace.
- InnoDB: A latch taken on the first page of a large object (LOB) was not released before another thread attempted to allocate the page, causing a deadlock.
- InnoDB: Converting an implicit lock to an explicit lock was optimized by the introduction of a member variable that tracks the smallest active transaction ID.
- Thanks to Zhai Weixiang for the patch.
- InnoDB: The mysql.innodb_ddl_log and mysql.innodb_dynamic_metadata tables, which are used internally by the InnoDB storage engine, are now protected. DDL and DML operations on these tables are no longer permitted, and the tables no longer appear in INFORMATION_SCHEMA query results.
- InnoDB: Upgrading a MySQL 5.7 instance with an innodb_page_size setting of 4K caused mysql_upgrade to fail with a “Specified key was too long; max key length is 768 bytes” error when creating or modifying system tables. The error was suppressed to permit the mysql_upgrade client to run on an instance with an innodb_page_size setting of 4K.
- InnoDB: The recovery process could not properly determine space_id values, causing the server to exit.
- InnoDB: An ALTER TABLE operation that modified the nullability of an indexed column raised an assertion. InnoDB incorrectly assumed that a new primary key must be added instead of created from an existing unique key.
- InnoDB: After an ALTER TABLE ... IMPORT TABLESPACE operation, metadata could not be retrieved correctly from the INFORMATION_SCHEMA.INNODB_COLUMNS table.
- InnoDB: An INSERT operation involving a large object (LOB) value raised an assertion. After splitting a LOB fragment, there was insufficient space for a directory entry.
- InnoDB: On a server using the utf8mb4 character set, an INSERT or UPDATE during an ALTER TABLE operation that changed the row format of a table that included a virtual column caused an index corruption.
- InnoDB: The data retrieved from INFORMATION_SCHEMA.INNODB_COLUMNS was incorrect for tables containing a virtual column.
- InnoDB: The server failed to start after recovery due to an invalid keyring file. The keyring file created from backup was empty.
- InnoDB: A deadlock between background threads, one attempting to evict a full-text search table from the cache, and the other attempting to synchronize a table, caused InnoDB Cluster nodes to fail.
- InnoDB: A typo was corrected in an InnoDB recovery message. Thanks to Daniël van Eeden for the patch.
- InnoDB: A message stating that encryption algorithm support is missing was reported during InnoDB recovery.
- InnoDB: A missing or mismatched keyring file caused an assertion failure at startup.
- InnoDB: An error was returned indicating that encryption support was missing when checking the space ID of an encrypted tablespace file.
- InnoDB: A debug message that prints a “too many open files” warning is now only printed if the number of open files reaches a limit of 300.
- InnoDB: Failure to skip predicate locks when releasing gaps locks raised debug assertions, as did failure to remove the supremum record bit prior releasing gaps locks on the supremum.
- InnoDB: A tablespace ID discovery failure occurred when starting the server on a cloned data directory.
- InnoDB: An unprotected global variable (fil_n_file_opened) caused an assertion when shutting down the server.
- InnoDB: An assertion that is no longer valid was raised when checking for pending I/O on the file in use.
- InnoDB: An empty general tablespace caused a failure when upgrading to MySQL 8.0. The empty data file was expected to have a specific number of pages.
- InnoDB: A startup failure occurred because a directory specified by the --innodb-directories option contained a keyring data file. The --innodb-directories option should only recognize InnoDB tablespace files.
- InnoDB: A function that calculates the increase in minimum bounding rectangle (MBR) size incorrectly returned 0, resulting in R-tree corruption.
- InnoDB: A REPLACE operation on a temporary table raised an assertion.
- InnoDB: An online ALTER TABLE operation on a table accompanied by concurrent DML on the same table raised an assertion. An end-of-log check was not performed prior to accessing the DML log to determine the length of a virtual column.
- InnoDB: When the addition of a virtual index failed, the virtual index that was freed was not removed from the lists of virtual column indexes.
- InnoDB: Adding a virtual column and index in the same statement caused an error.
- InnoDB: An undo tablespace truncate operation raised an assertion. The check that determines if undo tablespace segments are inactive was invalid.
- InnoDB: When the TempTable storage engine was unable to allocate memory using temporary files and mmap, an invalid error was reported indicating that the defined on-disk storage engine would be used instead.
- InnoDB: A tablespace import operation on a server with a default row format of REDUNDANT raised an assertion failure.
- InnoDB: A stored field based on a generated column permitted the base column to have a NULL value.
- InnoDB: Evaluation of a subquery in a resolving function raised an assertion.
- InnoDB: Locks related to data dictionary operations caused degradation in CREATE TABLE performance.
- InnoDB: A LOCK INSTANCE FOR BACKUP operation was able to acquire a backup lock without waiting for a concurrent DDL operation to finish.
- InnoDB: An incorrectly specified innodb_data_file_path or innodb_temp_data_file_path value returned a syntax error that did not specify the name of the system variable that caused the initialization failure.
- InnoDB: An handler that was opened for a TRUNCATE TABLE operation caused the operation to assert. The server now closes open handlers before dropping the table.
- The patch for this bug also improves TRUNCATE TABLE error messages related to foreign key constraints, and makes it possible to truncate a corrupted table.
- InnoDB: An online DDL operation that rebuilds the table raised an assertion when the last insert log record to be applied was split across two pages.
- InnoDB: An assertion was raised when attempting to generate a virtual column value dependent on an off-page large object value that was not yet stored.
- InnoDB: An R-tree search counted delete-marked records, causing it to find more records than present in the clustered index. As result, the valid R-tree index was marked as corrupted.
- InnoDB: A RENAME TABLE operation that renamed the schema failed to rename full-text search common auxiliary tables that were left behind when the full-text search index was removed previously, resulting in a assertion failure when attempting to drop the old schema.
- InnoDB: An assertion was raised when a thread attempted to read a record containing BLOB data while another thread was writing the same data to external pages.
- InnoDB: Column prefixes for externally stored columns exceeded the amount of available memory in the online log.
- InnoDB: A problematic lock that was introduced to protect writing of dynamic metadata changes to the redo log during a checkpoint was removed. A mutex is now used instead. The checkpoint LSN was also adjusted to protect dynamic metadata changes.
- InnoDB: InnoDB failed to account for a virtual column when using the column offset to search an index for an auto-increment column.
- InnoDB: An invalid debug condition caused a buffer pool chunk allocation failure, which resulted in an assertion failure when a purge thread attempted to access an unallocated chunk.
- InnoDB: Threads were prevented from entering the InnoDB storage engine due to ticket acquisition deadlocks.
- Partitioning: An error returned by the storage engine while executing ALTER TABLE EXCHANGE PARTITION was not handled correctly by the server.
- Replication: When MySQL was started with --plugin-load='group_replication.so' but Group Replication was not started, starting an asynchronous slave channel resulted in an unresponsive server.
- Replication: Empty XA transactions that have been rolled back should not be recorded in the binary log or added to the set of transactions in the gtid_executed system variable. However, if rolled-back empty XA transactions were executed after an empty XA transaction ending with an XA COMMIT ... ONE PHASE statement, they were being incorrectly added to the binary log as an XA ROLLBACK statement, and also to the gtid_executed system variable. The issue is now fixed.
- Replication: The Group Replication files have been moved from the rapid directory to the plugin directory.
- Replication: When the system variable gtid_next was set to AUTOMATIC, empty XA transactions that were rolled back and not recorded in the binary log, were being incorrectly added to the set of transactions in the gtid_executed system variable, causing an inconsistency. The rolled-back empty XA transactions are no longer recorded in gtid_executed.
- Replication: Group Replication conflict detection uses schema and table names as part of the Primary Key Equivalent (PKE) in order to detect and disallow conflicting transactions. The value of the lower_case_table_names system variable changes how schema and table names are stored and externalized, which depending on the configured value could persist a table named T1 as t1. Such a difference in a group could cause inconsistencies. Now, members must all have the same value for lower_case_table_names.
- Replication: Using an IP address or hostname in any Group Replication related configuration on macOS was failing.
- Replication: Changing the Group Replication required settings incorrectly on online secondary members could result in an unexpected halt.
- Replication: The value of LAST_CONFLICT_FREE_TRANSACTION in the replication_group_member_stats Performance Schema table was not correctly synchronized across group members.
- Replication: After issuing START GROUP_REPLICATION the gtid_mode system variable is locked to prevent any modification to its value until the group is online. Any attempt to modify gtid_mode during this time is blocked. As part of the process of starting Group Replication the server needs to set super_read_only=off, which has dependencies on locks acquired by SET GTID_MODE. This could result in Group Replication hanging and there was no possibility to connect to the server to resolve the situation. To prevent this situation, when it is not possible to acquire the locks needed by SET GTID_MODE the operation aborts.
- Replication: When a member is joining a group there is a chance of the request to join being rejected. If the rejection resulted in a retry, for example because the seed member being contacted was not in the group, then there was a possibility of the retry cycle continuing infinitely.
- Replication: In the unlikely event of the group failing to start, for example because no seed member could be contacted, there is a one minute period where the group retries the start process. Attempting to modify a Group Replication plugin option during this period could result in an unexpected halt. Now, attempting to modify a Group Replication plugin option during plugin start or stop results in error.
- Replication: The default binary log expiration period of 30 days is now set as the default for the binlog_expire_logs_seconds system variable, instead of the deprecated expire_logs_days system variable. binlog_expire_logs_seconds now defaults to a value of 2592000 (30*24*60*60 seconds), and expire_logs_days now defaults to zero.

In MySQL 8.0.3 and 8.0.4, the effects of binlog_expire_logs_seconds and expire_logs_days were cumulative. From MySQL 8.0.11, this is no longer the case, and the new behavior is as follows:
- If you specify a non-zero value for both variables, only the value of binlog_expire_logs_seconds is used to determine the binary log expiration period, and the value of expire_logs_days is ignored.
- If you specify a non-zero value for only one variable, that value is used to determine the binary log expiration period, and the default for the other is not applied.
- If you specify a value for neither of the variables, the default of 30 days from binlog_expire_logs_seconds is used as the binary log expiration period.
- An error message is issued if you attempt to set one of the variables dynamically when the other is already set, and a warning message is issued if you specify a non-zero value for both variables at startup. A deprecation warning is also issued if you set a value for expire_logs_days.
- To disable automatic purging of the binary log, specify a value of 0 explicitly for binlog_expire_logs_seconds, and do not specify a value for expire_logs_days. For compatibility with earlier releases, automatic purging is also disabled if you specify a value of 0 explicitly for expire_logs_days and do not specify a value for binlog_expire_logs_seconds. In that case, the default for binlog_expire_logs_seconds is not applied. You no longer need to set both variables to zero to disable automatic purging.
- Replication: Attempting to uninstall the Group Replication plugin on a server configured to start the plugin automatically at boot could result in a deadlock. Now, the uninstall process checks to ensure that the plugin is not in the process of starting and fails gracefully if it is.
- Replication: The DDL statements CREATE DATABASE, ALTER DATABASE, and DROP DATABASE are no longer allowed to execute in parallel with other statements on a multi-threaded slave. These statements require an exclusive metadata lock on the schema, causing a theoretical possibility of a deadlock when slave_preserve_commit_order=1 is set on the replication slave.
- Replication: On a replication slave with binary logging disabled, an empty DDL statement (for example, due to a replication filter) raised an assertion. With binary logging enabled, BEGIN and COMMIT statements would be written to the binary log to produce a transaction, but these statements were not available with binary logging disabled, causing the assertion. MySQL Server now checks for the situation where the DDL transaction is empty and is not marked as started, and handles it without raising the assertion.
- Replication: A new system variable rpl_read_size is available to set the minimum amount of data in bytes that is read from the binary log files and relay log files. The default read size is 8KB. If heavy disk I/O activity for these files is impeding performance for the database, increasing the read size might reduce file reads and I/O stalls if the files are not being cached by the operating system.
- Note that a buffer the size of this value is allocated for each thread that reads from the binary log and relay log files, including dump threads on masters and coordinator threads on slaves. Setting a large value might therefore have an impact on memory consumption for servers. Thanks to the Facebook team for the patch.
- Replication: On a server with GTIDs enabled, if RESET MASTER was used when a transaction had been flushed but not yet committed, the server GTIDs were left in an incorrect state. At this point, the GTID for the transaction had been added to the set of owned GTIDs, but not yet to the set of executed GTIDs. The GTID was removed from the binary log when the content of the uncommitted transaction was cleared by the RESET MASTER statement, but the GTID could not be reused because it was already owned, so the sequence of GTIDs had a gap.
- With this fix, RESET MASTER acquires a global read lock to ensure that no transactions are in commit stage during its operation, and no new transactions enter into commit stage during its operation. If there are any ongoing commits, RESET MASTER waits until they are complete. The global read lock is released when the reset is finished, and then storage engines are notified of the successful reset. If FLUSH TABLES WITH READ LOCK has already been executed for the thread, RESET MASTER does not retry the lock.
- Replication: Attempts to set a GTID for an unsafe or empty XA transaction using a SET @@SESSION.GTID_NEXT statement were not being handled correctly. On a server with gtid_mode set to OFF or OFF_PERMISSIVE, and enforce_gtid_consistency set to OFF, setting a GTID for an unsafe XA transaction (creating or dropping a temporary table) caused an inconsistency in the server's GTID violation counter and raised an assertion. Testing also showed that setting a GTID for an empty XA transaction caused an incorrect sequence of events to be written to the binary log. Both these situations are now handled correctly.
- Replication: The error message issued for a server stop while rotating the binary log did not state the correct cause for the issue. The error message has been enhanced to include the actual error causing the server stop as part of the message. A new error ER_OOM_SAVE_GTIDS has also been added for the situation where an out-of-memory error occurred while saving the set of GTIDs from the last binary log into the mysql.gtid_executed table.
- Replication: Group Replication uses transaction write set extraction for conflict detection on group members. A performance regression was found in this process during detailed performance analysis, which is handled by this bug fix. Memory allocation has been optimized for write set extraction and memory copy operations have been reduced. Also, foreign key write sets are now only collected when the current table has foreign keys.
- Replication: When using group_replication_ip_whitelist, it was possible to configure a group so that it functioned even though all members could not establish the internal group communication connection to each other, resulting in inconsistent behavior. Now, incoming connections are accepted if the IP is in the white list or if the IP belongs to a current member of the XCom configuration. This ensures members are always able to create the internal network required for group communication.
- Replication: The statements CREATE USER IF EXISTS (or IF NOT EXISTS) and ALTER USER IF EXISTS (or IF NOT EXISTS) were written to the binary log even when the query resulted in an error. MySQL Server now checks for errors that cause these queries to fail (for example, an invalid plugin was specified), and does not log the statement in that situation. Note that if these statements succeed but have no effect on the master because the condition is not met, the statements are written to the binary log, as the condition might be met on a replication slave.
- Replication: In a multi-primary group, when a member was also configured with a asynchronous replication channel, there was a possibility that the asynchronous channel could start before Group Replication started. This could result in the asynchronous channel processing transactions before the member became an online member of the group, causing issues when members tried to join the group. The fix ensures that asynchronous channels on group members do not start until the member has become online.
- Replication: Following the introduction of support for atomic DDL in MySQL 8.0, a replication slave that supports atomic DDL can diverge from a replication master at an earlier MySQL version that does not support atomic DDL. If the DDL statement can only be partly applied, the slave using MySQL 8.0 rolls back the whole DDL statement, but the master using an earlier version might commit the valid parts of the DDL statement. An error message is now logged in the event of an unsuccessful commit for an atomic DDL statement on the master and the slave, and you should check that the states of the master and the slave have not diverged before proceeding.
- Replication: When GTIDs are enabled on a replication master and slave, and the slave connects to the master with the MASTER_AUTO_POSITION=1 option set, the master must send the slave all the transactions that the slave has not already received, committed, or both. If any of the transactions that should be sent by the master have been already purged from the master's binary log, the master sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and replication does not start.
- The message provided for the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide advice on the correct action in this situation, which is for the slave to replicate the missing transactions from another source, or for the slave to be replaced by a new slave created from a more recent backup. The message advises that the master's binary log expiration period can be revised to avoid the situation in future. In addition, the master now identifies the GTIDs of the purged transactions and supplies them in its error log in the warning message ER_FOUND_MISSING_GTIDS (11809), so that you do not need to calculate the missing GTIDs manually.
- Replication: For updates to virtual generated columns containing the BLOB data type, both the old and the new BLOB values are required by some storage engines for replication. This fix extends the same behavior to JSON and GEOMETRY data types, which are based on the BLOB data type and so produce the same issue when the old value is not stored.
- Replication: A behavior change in MySQL 8.0.0 moved the identification of generated columns from before to after the calculation of the write set for binary logging. This caused an issue with NDB cluster replication, because that storage engine omits the generated columns from the log event if they are unnecessary, leading to NULL values being set for them by the applier thread on the replication slave. The identification of generated columns has now been moved back to before the write set calculation, so that the issue does not occur.
- Replication: On a multi-threaded replication slave (with slave_parallel_workers greater than 0), the slave's lag behind the master was not being reported by the Seconds_Behind_Master field for SHOW SLAVE STATUS. The value is now reported correctly. Thanks to Robert Golebiowski for the patch.
- Replication: A plus sign (+) can be used with a GTID set in the statement SET @@GLOBAL.GTID_PURGED to indicate that the specified GTID set does not intersect with gtid_executed. The plus sign was also being permitted for GTID sets specified for the functions GTID_SUBSET() and GTID_SUBTRACT(), where it was not meaningful. The plus sign can no longer be specified with these functions. Also, error messages relating to the SET @@GLOBAL.GTID_PURGED operation have been improved.
- Replication: When invoked with the options --read-from-remote-server and --hexdump, mysqlbinlog was not able to produce a hex dump of the binary log contents following an SQL statement that generated an autoincrement value, referenced a user-defined variable, or invoked RAND(). The event types for these events are followed by an informational row query log event, and mysqlbinlog caches the original event for printing when the subsequent row query log event is received. The pointer to the memory containing the original event was invalidated when the subsequent event was received, so the original data could not be accessed to produce the hex dump. The issue has now been fixed.
- Replication: A number of changes were made to the binary log decoding procedure to improve handling of invalid or corrupted binary log entries.
- Replication: Following the introduction of binary logging for XA transactions WL#6860, an assertion could be raised in debug builds during replication from a master with the feature to a slave without the feature, if MASTER_AUTO_POSITION=1 was set on the slave. The assertion has been removed, so that debug builds now have the same behavior as non-debug builds, and can attempt replication of unsupported event types whether or not MASTER_AUTO_POSITION=1 is set.
- Linux: Builds on Alpine Linux now take advantage of AIO support.
- macOS: On macOS, mysql_config --libs did not list any SSL libraries.
- Microsoft Windows: On Windows, the RESTART statement is implemented by having mysqld fork, with one process acting as a monitor to the other, which acts as the server. This makes determining the server process to attach to for debugging more difficult. To alleviate this, starting the server with --gdb now suppresses forking. A side effect is that for a server started with this option, RESTART simply exits and does not restart.
- JSON: The JSON_QUOTE() function could in some situations write the quoted string to the same buffer that holds the input string, which could lead to wrong results. Now a check is made to be sure that it does not attempt write into the same buffer that it is reading from.
- JSON: JSON_SEARCH() no longer performs any modification of cached Json_path objects, now making any needed updates to a String object that represents the path instead. This saves on the number of round trips required between the path's Json_path and String representations, which speeds up execution. In addition, the one_or_all and escape_char arguments to JSON_SEARCH() were unnecessarily cached; these arguments are no longer cached, which should also improve this function's execution time.
- A check was implemented based on data dictionary version information to prevent starting the MySQL 8.0 server with a data directory created by a later MySQL release. The check was necessary to prevent an in-place downgrade, which is currently not supported.
- Protected data dictionary tables are no longer accessible by statements placed in a server initialization file.
- Data dictionary and INFORMATION_SCHEMA version numbers were synchronized with the new MySQL server version number.
- The server did not handle correctly certain LIKE queries using a BLOB column with a prefix index.
- For builds configured using -DWITH_PROTOBUF=SYSTEM, building failed on systems with ProtoBuf 3.5 installed.
- The microseconds part of timestamps stored with persisted variables in mysqld-auto.cnf was always 000000.
- Debian packages now handle dependencies for MeCab plugin dictionary files. Fedora packages now handle dependencies for both MeCab packages, not just the utf-8 package.
- The change in MySQL 8.0.11 for platforms that use systemd to run mysqld as a normal process (Type=notify) and communicate using a socket file did not work on SLES before SLES 12.2.
- The NON_UNIQUE column in the INFORMATION_SCHEMA.STATISTICS table had type BIGINT prior to MySQL 8.0, but became VARCHAR in MySQL 8.0 with the introduction of the data dictionary. The NON_UNIQUE column now has an integer type again (INT because the column need not be as large as BIGINT).
- With some inputs, ST_Crosses() could cause a server exit.
- Some error messages were being written to the error log with an error ID of 0 rather than a legitimate error ID.
- mysql_upgrade did not set MYSQL_SERVER_PUBLIC_KEY correctly, leading to failure to read the key file.
- If autocommit was disabled, mysql_upgrade produced an error when upgrading from MySQL 5.7 to 8.0.
- For debug builds, displaying very long stage names from the PROCESSLIST_STATE column of the Performance Schema threads table could raise an assertion.
- Group Replication failed to start if certain required variables had been set as persisted variables, or if persisted variables were not set in proper timestamp order.
- gtid_purged handling had a memory leak.
- Using SET PERSIST to persist optimizer_trace_offset resulted in an incorrect variable value after server restart.
- The validate_password component could leak memory.
- A typo in sql/handler.h was corrected. Thanks to Su Tristan for the patch.
- The Performance Schema variables_info table displayed incorrect VARIABLE_SOURCE and VARIABLE_PATH values for variables set within option files specified by !include or !includedir directives.
- After upgrading from MySQL 5.7 to MySQL 8.0, the first attempt to start the server on a MySQL 5.7 data directory with --default-time-zone set to a specific time value such as "+00:00" caused the server to exit.
- Lookups of character set internal numbers was not thread safe and could cause memory leaks.
- Using the -DWITH_LIBEVENT=system and -DWITH_ICU=system CMake options together caused configuration to fail.
- Some messages were being written to the server error log using client error IDs.
- When run in key migration mode, the server could report an error for successful operations.
- Upgrades from MariaDB to MySQL Community Edition failed on Fedora 27.
- ALTER TABLE could hang in a Waiting for tablespace metadata lock state.
- Selecting from the Performance Schema status_by_thread or variables_by_thread table was not thread safe and could yield incorrect results.
- INSERT ... ON DUPLICATE KEY UPDATE could be handled improperly if a source table produced no rows.
- SET PERSIST_ONLY ignored --skip-grant-tables and continued to perform checking against the dynamic privileges needed to set system variables.
- For RPM packages and Docker RPM packages, the included my.cnf file now includes information indicating how to revert to the previous default authentication plugin (changing caching_sha2_password to mysql_native_plugin), for compatibility with older clients.
- In string comparisons using >, only one operand was handled as utf32.
- A server exit during InnoDB initialization caused AddressSanitizer (ASan) to report a memory leak. The patch also implements proper handling of the data dictionary properties table in cases where the table contains data that cannot be parsed.
- With -DWITH_SSL=system, if CMake could not find the system OpenSSL libraries and header files, it produced confusing messages. Now it exits immediately with an error.
- Configuring with -DWITH_INNODB_EXTRA_DEBUG=ON resulted in a linker error.
- Configuring with -DWITH_ZLIB=system resulted in a linker error.
- Metadata from result sets for UNION ALL queries could say NEWDATE rather than DATE.
- In builds with Undefined Behavior Sanitizer enabled, negation of -922337203685477580 could cause a server exit.
- With protocol compression enabled, a spurious assertion could be raised.
- Performance related to fetching tablespace objects from the data dictionary to populate the data dictionary cache was improved.
- If the server was started with --skip-grant-tables, clients that authenticate using the caching_sha2_password plugin were unable to connect.
- Linux RPM and Debian packages now include dependency information for the Perl JSON module required to run the MySQL test suite. Linux RPM packages now include dependency information for the Perl Digest module required to run the MySQL test suite.
- A new system variable, default_collation_for_utf8mb4, enables setting the default collation for the utf8mb4 character set. This variable is primarily intended to support replication from a MySQL 5.7 or older master server to a MySQL 8.0 slave server, or group replication with a MySQL 5.7 primary node and one or more MySQL 8.0 secondaries. The value of the variable is replicated to the slave so that the slave can correctly process data originating from a master with a different default collation for utf8mb4. It may be helpful because the default collation for utf8mb4 in MySQL 5.7 is utf8mb4_general_ci but utf8mb4_0900_ai_ci in MySQL 8.0.

The variable value determines the default utf8mb4 collation for the following statements:
- SHOW COLLATION and SHOW CHARACTER SET.
- CREATE TABLE and ALTER TABLE having a CHARACTER SET utf8mb4 clause without a COLLATION clause, either for the table character set or for a column character set.
- CREATE DATABASE and ALTER DATABASE having a CHARACTER SET utf8mb4 clause without a COLLATION clause.
- Any statement containing a string literal of the form _utf8mb4'some text' without a COLLATE clause.
- DESCRIBE with a column name option ignored the column name.
- When run in key migration mode, the server ignored invalid options.
- Path name normalization could fail for very long path names.
- During configuration, CMake assumed that rpcgen was available rather than checking for it.
- The client authentication process could use memory after it had been freed.
- -DWITH_ZLIB=system could cause other CMake feature tests to fail.
- On some systems, using mysqld --initialize to initialize the data directory was very slow.
- Builds using RPM source packages now use a secure connection if Boost must be downloaded.
- An internal check_datetime_range function that converted an ULONGLONG time value raised an assertion on Windows.
- Too much locking was being done for the caching_sha2_password authentication plugin (one lock/unlock per connection). This is now improved to one lock/unlock per plugin install/uninstall.
- A CREATE TABLE ... LIKE operation that implicitly assigned 'innodb_system' as the tablespace name for table partitions raised an assertion.
- SET PERSIST_ONLY could store large-valued variables incorrectly.
- The audit_log plugin could write statements to the binary log even with binary logging disabled.
- Certain queries using GREATEST() or LEAST() produced heap-use-after-free errors.
- An external_language column was added to the mysql.routines data dictionary table to support stored routines in different languages. The data stored in this column can be accessed through the EXTERNAL_LANGUAGES column of the INFORMATION_SCHEMA.ROUTINES table.
- It is now prohibited to start the server with a lower_case_table_names setting that is different from the setting used when the server was initialized. The restriction is necessary because collations used by data dictionary table fields are based on the setting defined when the server is initialized, and restarting the server with a different setting would introduce inconsistencies with respect to how identifiers are ordered and compared.
- For accounts that authenticated using the auth_sock authentication plugin, the server was unable to accept connections from clients from older MySQL versions.
- An audit_log plugin memory leak was corrected.
- The INFORMATION_SCHEMA.FILES table now obtains from storage engines the information needed for the following columns: LOGFILE_GROUP_NAME, LOGFILE_GROUP_NUMBER, ROW_FORMAT, VERSION.
- Dropping a user-defined function did not always remove its entry from the Performance Schema user_defined_functions table.
- To reduce its size and storage footprint, Serialized Dictionary Information (SDI) is now generated in a compact JSON format.
- Concurrent execution of RESET PERSIST and SET PERSIST from multiple sessions could cause a server exit.
- Tablespace statistics could be cached even if the statistics-collection process encountered an error.
- SET PERSIST could fail to find the proper directory into which to write the mysqld-auto.cnf file.
- ALTER TABLE could not create generated NOT NULL geometry columns if the table contained data.
- The Performance Schema variables_info table displayed incorrect VARIABLE_SOURCE values for variables that were set in my.cnf and also persisted to mysqld-auto.cnf.
- Improper handling of plugin loading and unloading could cause a server exit.
- The RESTART statement did not work for Ubuntu packages.
- LDAP authentication plugins were not built on FreeBSD.
- The server did not handle queries correctly when a cached value was evaluated as NULL by a windowing function, or when its argument was part of a GROUP BY with a ROLLUP operation which could be evaluated as NULL.
- Windowing functions such as LAST_VALUE() did not work correctly with tables containing NOT NULL columns in all cases.
- Role cache invalidation could be performed incorrectly.
- Incorrect handling of persisted variables at server startup could result in a server exit.
- For upgrades from MySQL 5.7 to 8.0, the sql_mode value for object definitions could contain NOT_USED.
- JSON_TABLE() failed if no default database was selected.
- Adding a unique index to an InnoDB table on which multiple locks were held could raise an assertion.
- CREATE VIEW statements that used JSON_TABLE() in the view definition failed if no database was selected.
- Queries on Performance Schema replication tables could return incorrect results, particularly when the execution plan used an index.
- For some statements, the FILE privilege was not properly checked.
- To better enable setting persisted variables at startup in the same order they were persisted with SET PERSIST, settings in mysqld-auto.cnf are first sorted based on timestamp (which is now stored in the file).
- Setting the dragnet.log_error_filter_rules system variable to a very long value could cause a server exit.
- For platforms that use systemd (see Managing MySQL Server with systemd), systemd was not always able to infer the state of a double-forked mysqld process. Consequently, systemd would attempt to restart mysqld even when that process terminated with status 1. systemd is now configured to run mysqld as a normal process (Type=notify rather than Type=forking). If the name of a socket file is specified in the environment variable NOTIFY_SOCKET, mysqld attempts to open a connection for communicating with systemd and writes its state changes there.
- ST_IsValid() returned incorrect results for some geographic polygons on non-WGS 84 ellipsoids.
- A multiple-insert statement on a table containing a FULLTEXT key and a FTS_DOC_ID column caused a server error.
- In strict SQL mode, assignment of invalid values to AUTO_INCREMENT columns could be handled incorrectly, resulting in an assertion being raised.
- Thread stack exhaustion could raise an assertion rather than returning an error.
- SET PERSIST_ONLY did not properly consider whether the runtime validation function for persisted variables should be invoked.
- The audit_log plugin could mishandle aborts of event executions, causing a server exit.
- Some boundary cases for negation of large signed integers were corrected.
- An ALTER TABLE operation attempted to set the AUTO_INCREMENT value for table in a discarded tablespace.
- MyISAM index corruption could occur for bulk-insert and table-repair operations that involve the repair-by-sorting algorithm and many (more than 450 million) rows.
- The Performance Schema could produce DIGEST_TEXT values with a trailing space. This no longer occurs.
- Dropping an index from a system table could cause a server exit.
- A prepared statement using CREATE TABLE ... SELECT led to unexpected behavior when it referred in a GROUP BY to a view having the same name.
- With auto-commit disabled and an XA transaction in PREPARED state, attempts to execute XA COMMIT or XA ROLLBACK failed.
- Some diagnostic messages produced by LDAP authentication plugins misleadingly suggested an error when no error had occurred.
- Initialization code for mysql_upgrade and mysqlpump was reorganized to avoid assertion failures.
- Full-text searches could raise an assertion due to improper handling of errors that occurred while attempting to acquire metadata locks.
- A keyring file created by the keyring_file plugin on a 32-bit server was inaccessible by the keyring_file on a 64-bit server, and vice versa.
- Metadata locks for column statistics were not displayed properly in the Performance Schema metadata_locks and events_waits_xxx tables.
- The my_snprintf plugin service was removed and reimplemented using C++11 snprintf.
- After an in-place upgrade from MySQL 5.7 to MySQL 8.0 on a server with a large number of tables, server startup failed to complete due to excessive memory consumption during data dictionary creation.
- An error occurring in a statement that modifies user privileges could result in deadlock for other transactions attempting to access the user privilege cache.
- The thread pool plugin logged too much information for failed connections.
- Enabling multiple components concurrently could result in a server exit.
- A malformed mysqld-auto.cnf file could cause a server exit.
- Creating a table in a reserved tablespace did not return an error.
- For debug builds, using KILL to terminate a stored routine could raise an assertion. Thanks to Laurynas Biveinis for the patch.
- If the init_connect system variable was set, its contents could not be executed by clients with expired passwords, who therefore were prevented from connecting. Now, if a client has an expired password, init_connect execution is skipped, which enables the client to connect and change password.

Dates using the YYYYMMDD format were not recognized correctly in a query meeting all three of the following conditions:
- The query performed a left join.
- A DATE column in the inner table of the join was part of a multi-column primary key.
- Every column in the inner table's primary key was compared with another value; this could be either a literal or a column value.
- An in-place ALTER TABLE operation on a table with foreign keys resulted in a table definition mismatch. The new table definition passed to storage engine methods during the ALTER TABLE execution contained invalid foreign key names.
- It was possible to assign nonexistent roles to an account as its default roles.
- Using the C API, when trying to execute an INSERT prepared statement with CURSOR_TYPE_READ_ONLY set, the client hung.
- RENAME USER failed even though the user or role to be renamed was not present in any role graph.
- MySQL client programs could exit unexpectedly if malformed client/server protocol packets were received.
- Memory statistics collected by the Performance Schema could be incorrect due to race conditions.
- Incorrect handling by the CONNECTION_CONTROL plugin of an internal hash led to spurious messages in the error log and eventual server exit.
- CURRENT_ROLE() and ROLES_GRAPHML() now return a string with the utf8 character set. Previously, they incorrectly returned a binary string.
- Killing INSTALL COMPONENT or UNINSTALL COMPONENT could result in multiple rows for a single component in the mysql.component system table.
- Performing SHOW PROCESSLIST while running a high load concurrently using the X Plugin could lead to an unplanned server exit.
- The regular expression implementation in MySQL uses a String object—intended to be initialized as empty—to hold the current subject, and used the literal "" for this value. This could interfere with other functions that do likewise. This is fixed by constructing the String with a nullptr instead.
- mysqlpump could leak memory or exit when errors occurred.
- LDML 2.8 collation definitions could cause unexpected server behavior.
- Log-opening operations accessed log-name system variables without holding a lock on them. Multiple threads accessing such a variable could lead to a race condition and unexpected server behavior.
- When the range optimizer computed the prefix for a string of sufficient length, it was possible for it to truncate the string in the middle of a character, which could lead to assertion and other failures in debug builds. Now steps are taken in such cases to make sure that the string is truncated at a character boundary.
- Queries having subqueries or expressions in the GROUP BY clause could in some situations return random results, due to reading of uninitialized data.
- The audit_log plugin did not log placeholder values for prepared statements.
- Integer columns in UNION statements could be cast to BIGINT even if a smaller integer type was more appropriate.
- Added ER_REGEXP_INVALID_CAPTURE_GROUP_NAME (Error 13110).
- Window function row-buffer handling has been refactored to reduce the number of handler reads by 25%.
- For some frames, the functions VARIANCE(), VAR_POP(), and VAR_SAMP() produced wrong results when evaluated with the windowing_use_high_precision system variable set to false.
- Generated columns with a prefix index were not considered when the optimizer attempted to substitute an expression with an equivalent generated column. This prevented use of prefix indexes to speed up queries with predicates employing a generated column expression.
- FIRST_VALUE() did not always return NULL for an empty frame.
- Regular expression functions accepting optional arguments did not return NULL as expected when one or more of these arguments was passed as an explicit NULL.
- Row-based replication used the wrong set of indexes on the slave.
- When executed with no default database having been chosen, EXPLAIN EXTENDED raised Error 1046 No database selected instead of the SQL syntax error expected due to the fact that the EXTENDED keyword has been removed.
- The CMake option OPTIMIZER_TRACE=0 had no effect on builds and so is no longer used.
- A SELECT statement using GROUP BY with no constant or aggregate column failed a check for functional dependencies, correctly, on the first attempt but succeeded, wrongly, on the next.
- A CREATE TABLE ... SELECT statement with a UNION in the SELECT failed in strict mode for a DATE column declared as NOT NULL.
- Prepared statements using nested sub-selects were not always handled correctly.
- The cost estimates for a query containing window functions did not take into account the cost of PARTITION BY or ORDER BY, nor did they include the cost of using the frame buffer.
- When processing a query with a subquery, the subquery is no longer optimized if outer query is known to produce an empty result; in such cases, EXPLAIN now shows Not optimized, outer query is empty.
- This change is made because, when the table used by the outer query is found empty at optimization, this sets the join column to NULL even when defined as not nullable, which leads to a conflict when optimizing the subquery.
- An exception is made if the outer query has aggregates without any GROUP BY; this means that it has a non-empty result, and that any subquery in the SELECT list must be evaluated and optimized, which reopens the nullability issue, which is now handled correctly for such cases.
- When selecting from all columns making up a unique key containing nullable columns, with all columns in the WHERE condition set to non-null values, MySQL did not take into account their uniqueness, with the result that only_full_group_by missed detecting a functionally dependent column.
- When using a partial index, the optimizer performed a more expensive table lookup instead of using the index, even when the partial index covered the entire set of data needed.