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.40 (2024-10-15, General Availability)

Changes in MySQL 8.0.40 (2024-10-15, General Availability)

C API Notes

  • The asynchronous interface used unsafe static local variables to store state information. (Bug #115703, Bug #36891894)

Compilation Notes

  • MySQL did not compile on Fedora 41. (Bug #37046924)

  • MySQL did not compile on Ubuntu 24.10. (Bug #37042308)

  • Added CONTRIBUTING.md and SECURITY.md files to the MySQL sources to conform to Oracle's Open Source guidelines. (Bug #36998165)

  • Aligned CMAKE_MINIMUM_REQUIRED with the correct required CMake version (3.14.6) as well as CMake policies for third-party libraries used by MySQL. (Bug #36978193)

  • Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 8.9.1. Important issues fixed in curl version 8.9.1 are described at https://curl.se/docs/security.html. (Bug #36967379, Bug #36955197)

  • The included zlib library has been upgraded from version 1.2.13 to version 1.3.1. (Bug #36950863)

  • CMake options BUILD_SHARED_LIBS and CMAKE_SKIP_INSTALL_ALL_DEPENDENCY are now set to OFF in the top level of the build. (Bug #36930664)

  • Upgraded the bundled libcurl library to version 8.9.0. (Bug #36886877)

  • The bundled lz4 library was upgraded to version 1.10.0. (Bug #36886747)

  • The -DWITHOUT_SERVER option for CMake did not work on Enterprise Linux 7. (Bug #36824515)

  • The version of libfido used with MySQL was upgraded to 1.15.0. (Bug #36752604)

  • The version of clang-format used for the MySQL codebase was upgraded from 10 to 15. (Bug #36500268)

  • The bundled version of TI-RPC was upgraded to 1.3.5. (Bug #115698, Bug #36886602)

  • It was not possible to build MySQL using Protobuf 22 or later.

    Our thanks to Gordon Wang for the contribution. (Bug #115163, Bug #36678092)

SQL Function and Operator Notes

  • The output from DATABASE() was truncated when this function was used as part of a UNION query. (Bug #36871927)

Performance Schema Notes

  • Redesigned the performance schema data_locks and data_lock_waits tables so that querying them does not require an exclusive global mutex on the transaction or lock system. It now iterates over buckets of hash tables that hold the locks to only latch the actively processed shard, when previously it iterated over the transactions. This also improves the iteration logic complexity in terms of speed and memory to decrease the impact of these queries on the rest of the system.

    Note that the query result might show an incomplete list of transaction locks if it committed, started, or otherwise changed the set of owned locks in-between visiting two buckets. This differs from previous behavior which always showed a consistent snapshot of locks held by individual transactions, although two different transactions could have been presented at different moments. In other words, the new approach gives a consistent view of a single wait queue to show conflicting locks with a waiting lock because they are always in the same bucket, while the old approach could miss some of them because they belonged to other transactions. The old approach would always show all the other locks held by a reported transaction but could miss locks of other transactions even if they were conflicting. (Bug #112035, Bug #113761, Bug #36302624, Bug #36015586, Bug #36690035, Bug #35712638, Bug #36891888)

  • Running SELECT * FROM sys.innodb_lock_waits; on an instance which was under heavy load affected the performance of the server.

    As of this release, SELECT * FROM sys.innodb_lock_waits; fetches only 2 locks for each wait, instead of scanning all locks twice for each wait.

    As part of this fix, primary keys were added to DATA_LOCKS and DATA_LOCK_WAITS. (Bug #100537, Bug #31763497)

sys Schema Notes

  • The performance of the innodb_lock_waits view is improved in this release. (Bug #36337708)

Thread Pool Notes

  • Some concurrent connection attempts were not handled correctly. (Bug #36625082)

Functionality Added or Changed

Bugs Fixed

  • Performance; InnoDB: Several functions internal to InnoDB, which were defined as inline in MySQL 8.0.28, were found to be no longer inline in MySQL 8.0.33, due in part to refactoring which accompanied improvements made in MySQL 8.0.30 to improve the InnoDB adaptive hash index. This had an adverse effect on queries using joins on InnoDB tables. (Bug #111538, Bug #35531293)

    References: This issue is a regression of: Bug #81814, Bug #16739204, Bug #23584861.

  • InnoDB: InnoDB did not allow updating a REDUNDANT table column that was altered with NULL as the default value using the INSTANT algorithm. Instead, MySQL unexpectedly halted. (Bug #36840107)

  • InnoDB: When redo log capacity was reduced with log_files_truncate, under rare circumstances the file.end_lsn equaled log_sys->write_lsn thus disallowing future redo log writes. (Bug #36730830)

  • InnoDB: It was possible for the MySQL server to halt unexpectedly when executing a DELETE or UPDATE statement after a column was dropped using the INSTANT algorithm. (Bug #36723117)

  • InnoDB: FTS index optimization would sometimes not function correctly with tokens equal in collation order but different in terms of bytes. (Bug #36652127)

  • InnoDB: Replaced std::this_thread::sleep_for(std::chrono::seconds(0)) usage with std::this_thread::yield() to prevent it from being optimized out while compiled. (Bug #36522343)

  • InnoDB: The upgrade process unexpectedly halted when the database contained a full-text index created in MySQL 5.7 with a user-created FTS_DOC_ID column as the primary key.

    Our thanks to Huaxiong Song and the team at Alibaba for contributing to this fix. (Bug #36496164)

  • InnoDB: Disabled the optimizer for indexes with range conditions on multiple-value virtual columns. (Bug #36341532)

  • InnoDB: On Windows, fixed a doublewrite buffer regression that slowed file access, and refactored FILE_FLAG_OVERLAPPED flag usage for opening files. (Bug #36259487)

  • InnoDB: A schema mismatch was possible when a table was imported with a different sql_mode than when it was created, because strict mode influences the number of nullable columns in a table's secondary index. Now the secondary index trees are also checked for corruption after a tablespace is imported. (Bug #35799038)

  • InnoDB: Given a table with an FTS index, when its tablespace is discarded the corresponding FTS tables are also dropped. When performing an operation that cleared out these tables, the code incorrectly assumed that the FTS tables must also exist if the FTS indexes were present in the table metadata. (Bug #35343458)

  • InnoDB: An uninitialized buffer was being written to a temporary file when checking if the system supports a different sector size for FusionIO. This check is made when innodb_flush_method is set to O_DIRECT or O_DIRECT_NO_FSYNC. (Bug #115229, Bug #36705034)

  • InnoDB: Table rebuild operations involving secondary indexes required greater file I/O for InnoDB temporary files as compared with MySQL 8.0.26, which degraded query performance. (Bug #114465, Bug #36444172)

  • InnoDB: Adding indexes with the parallel index builder was much slower with the Performance Schema enabled due to issues in the Alter_stage class. (Bug #113505, Bug #36163502)

  • InnoDB: Fixed an innodb.parallel_read_kill related unit test to better account for recent optimizer changes, and fixed an innodb.ddl_kill unit test and its associated macro usage.

    Our thanks to Dmitry Lenev and the team at Percona for contributing to these fixes. (Bug #113002, Bug #115416, Bug #35992036, Bug #36764973)

    References: See also: Bug #112767.

  • Partitioning: ALTER TABLE did not always work correctly with partitioned tables. (Bug #36677952)

  • Group Replication: Under certain conditions, all secondaries shut down unexpectedly following a brief period of network inactivity on the primary host. (Bug #35642087)

    References: See also: Bug #32673639, Bug #34565855.

  • Group Replication: Memory aggregated by threads as reported did not account for all memory/sql/Gtid_set::Interval_chunk freed by other threads from what was allocated, leading to a incorrect ever-increasing consumption of resources by Group Replication thread thread/group_rpl/THD_applier_module_receiver.

    Global memory as reported by performance_schema.memory_summary_global_by_event_name was not affected by this issue. (Bug #34819861)

  • Group Replication: Removed a potential memory leak from xcom\network\xcom_network_provider_native_lib.cc. (Bug #115162, Bug #36673883)

  • The server did not always handle connections correctly when running with both the thread pool and audit log plugins. (Bug #37039422)

  • Packages for Debian-based systems are now built with WITH_ZLIB=system, and disable MYSQL_MAINTAINER_MODE for debug builds. (Bug #37038213)

  • Updated the Kerberos library bundled with commercial builds to version 1.21.3. For more information, see the Kerberos 5 1.21.x Release Notes. (Bug #37034600)

  • Removed a heap-use-after-free warning in regexp::Regexp_facade::~Regexp_facade(). (Bug #36867806)

  • While dumping tablespaces, mysqldump did not properly escape certain SQL statements in its output. In addition, the dump now encloses the following identifiers within backticks: LOGFILE GROUP, TABLESPACE, and ENGINE. (Bug #36816986)

  • A previous fix for an issue in sql/sql_executor.cc checked for const_item() rather than const_for_execution(). (Bug #36804785)

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

  • When executing an index range scan using IndexRangeScanIterator the record buffer was never set due to the fact that the data type used for IndexRangeScanIterator::m_expected_rows had been changed from double to boolean during refactoring. This unintended change has been reverted.

    In addition, when the record buffer was enabled for index range scans a problem arose with multi-valued indexes used for covering these scans. (This is possible only when they are used as part of index merge scans, since index merge scans force covering index scans.) The source of the problem was that the implementation of Field_typed_array::key_cmp() needs the value of the generated column for the indexed expression, and this column is not available in the multi-valued index, so the storage engine cannot safely evaluate the end range condition when filling the record buffer for a covering scan. To fix this, we now disable the record buffer when multi-valued indexes are used for covering index range scans. (Bug #36775910)

    References: See also: Bug #36341532.

  • Certain triggers and stored procedures were not handled correctly. (Bug #36775910)

  • Some errors raised when referencing external tables were not handled correctly. (Bug #36758378)

  • On Debian, stopped stripping libmysqlclient.a to increase LTO build compatibility. (Bug #36737581)

  • The internal function my_convert_internal() sometimes returned a pointer rather than the intended value. (Bug #36684463)

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

  • Removed a memory issue in the server component. (Bug #36600205)

  • Fixed a memory leak in the mysql client. (Bug #36600203)

  • The AES_ENCRYPT() function did not always return a valid result. (Bug #36593265)

  • In some cases a join involving a very large number of rows and many tables was not processed correctly. (Bug #36562979)

  • DROP INDEX with the addition of a FULLTEXT index in the same transaction sometimes led to an unplanned server exit. (Bug #36559642)

  • Some combinations of optimizer hints did not function correctly. (Bug #36492114)

  • Following the fix for a previous issue, a const item that is part of a GROUP BY and is not found in the select list is not added as a hidden item to the field list, but this was not taken into consideration while checking for replacements for expressions involving ROLLUP operations while creating a temporary table. We fix this by checking whether the item that is not found in the field list is a const item, and if so, we use the same item as a replacement. (Bug #36444257)

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

  • Removed assertions found during testing of the data masking functions gen_rnd_pan() and mask_ssn(). (Bug #36397869, Bug #36398272)

    References: See also: Bug #36398221.

  • Fixed an issue relating to FTS comparisons.

    Our thanks to Shaohua Wang and the team at Alibaba for the contribution. (Bug #36210202)

  • RelWithDebInfo builds are no longer compiled with the "-g1" flag, thus increasing the available debugging information and generated file sizes. (Bug #36111629)

    References: See also: Bug #33664929.

  • Corrected potential misbehavior when the server was run with --skip-grant-tables. (Bug #36043213)

  • Fixed a regression in an earlier fix for a problem with references to columns from tables of outer query blocks in the ON condition of a join. (Bug #35854686)

    References: This issue is a regression of: Bug #96946, Bug #30350696.

  • In certain rare cases, a CREATE TABLE statement involving the creation of a table with foreign keys was not processed correctly. (Bug #35553557)

  • Fixed an issue relating to SHOW INDEX and generated columns. (Bug #35497623)

  • In some cases, table DDL in prepared statements was not handled correctly. (Bug #35221658)

  • Changed the SLES 15 target platform from openSUSE 15.5 to 15.6, which also means using GCC 13 instead of GCC 12 and building against the system's OpenSSL 3.x instead of OpenSSL 1.1.x. (Bug #115535, Bug #36934913)

  • Fixed a typo in the Debian package description.

    Our thanks to Henning Pƶttker for the contribution. (Bug #115363, Bug #36749142)

  • With prefer_ordering_index=off, a query with no reference key reverted to scanning and sorting the full table even though it should have been possible to avoid the sort.

    Our thanks to Daniel Nichter for the contribution. (Bug #113699, Bug #36213938)

  • A query using a greater-than (>) or less-than (<) comparison with a multi-valued index executed much more slowly than the same query using an equality (=) comparison with the same index. (Bug #104897, Bug #33334911)