dev.mysql.com

  • 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: Removed the DEBUG_SYNC_C_IF_THD macro in favor of DEBUG_SYNC. (Bug #36870544)

  • 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: Improved error handling for bulk load operations with tables containing a mix of BLOB and other data types. Previously, the error type was reported as an empty string. (Bug #36764710)

  • 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: The log index size calculation now accounts for column order changes. (Bug #36526369)

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

  • 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: 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 #36302624)

  • InnoDB: Fixed a memory leak in the bulk loader. (Bug #35988311)

  • InnoDB: For tables created with an index on a column that was too wide for the redundant row format (allowed before MySQL 5.7.35), an in-place upgrade silently imported the table but it was not accessible, which interfered with making backups. Now all operations that involve using the invalid index are rejected with ER_INDEX_CORRUPT until the index is dropped. An ER_IB_INDEX_PART_TOO_LONG error is also reported in the error log. (Bug #35869747)

    References: See also: Bug #34826861.

  • 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)

  • For a subquery which uses window functions in its SELECT list, an EXISTS() transformation cannot be used; this means that, for such a subquery, the transformation used is always materialization, but this is true only when the subquery uses one of IN, ALL, ANY, or SOME. The check for whether materialization is forced (IsForcedMaterialization()) for a subquery returned true when the query had an IN subquery whose WHERE clause used an EXISTS subquery containing window functions, due to the fact that the innermost subquery having window functions always returned its strategy as materialization, even though the EXISTS strategy had already been chosen for the IN subquery. As a result, some checks failed when this subquery was considered for materialization.

    We fix this by adding a check for a quantified comparison predicate in IsForcedMaterialization(), so that the subquery with a window function is not looked into. (Bug #37008930)

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

  • Some combinations of EXCEPT and INTERSECT led to an error in Item::convert_charset(). (Bug #36838373)

  • 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)

  • Eliminated unnecessary copying in StoreLinkedImmutableStringFromTableBuffers(), improving the performance of some hash joins by 5 to 10 percent. (Bug #36805260)

  • 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 calculating Last_query_cost, the optimizer did not always take the costs of all subqueries into account. (Bug #36790906)

  • 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)

  • When the argument to COUNT() used as a window function was a GROUP BY expression and WITH ROLLUP was used, COUNT() returned NULL instead of 0. (Bug #36750571)

  • 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)

  • Preparation of table value constructors did not track the number of hidden columns added for expressions in an ORDER BY clause. This could cause problems later in the resolution process, possibly leading to an unplanned server exit.

    We fix this by counting the number of hidden items in table value constructors in the same way as this is done in other query blocks. (Bug #36560156)

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

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

  • Fixed an issue related to the handling of FTS indexes during an upgrade. (Bug #36526587)

  • 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.

  • If an expression involved in condition pushdown had one view reference which was also an outer reference and one local reference, then dependency consistency checks failed while cloning the condition.

    We solve this by traversing the item tree prefix and postfix. While traversing the prefix, we set the Item_ref object to be used for setting dependency and context information for the underlying columns of the reference object; while traversing the postfix, we clear this object. (Bug #36368181)

  • Some prepared statements were not reprepared correctly. (Bug #36267792, Bug #35712413)

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

  • Fixed an issue relating to FTS comparisons.

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

  • Some CREATE TABLE ... SELECT statements were not always processed correctly. (Bug #36138460)

  • 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)

  • When converting a string to a MYSQL_TIME struct, we did not always verify that the day number was less than or equal to 31. (Bug #35884337, Bug #36633426)

  • 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, Bug #36350852)

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

  • Removed a memory leak from the FEDERATED storage engine that was discovered during testing of queries using index merge plans. (Bug #35362984)

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

  • A statement which called a stored routine containing an aggregate function, whose result was stored in a variable local to the routine, raised an assert in sql/sql_lex.h. (Bug #35102083)

  • In a UNION, it was sometimes possible for one of the SELECT statements involved to reference a column in an ORDER BY clause when this column was not among those accessed by that SELECT. (Bug #35058815)

  • Running two concurrent OPTIMIZE TABLE statements on the same table with fulltext indexes and innodb_optimize_fulltext_only enabled sometimes caused the server to exit. (Bug #34929814)

  • A left join with an impossible condition as part of an ON clause was not optimized as in MySQL 5.7, so that, in later versions, the query executed more quickly without the impossible condition than with it. An example of such a query, impossible condition included, is SELECT * FROM t1 JOIN t2 ON t1.c1=t2.c1 AND 1=2. (Bug #34668756)

  • The XML function ExtractValue() did not handle arguments containing accented characters correctly. (Bug #117778, Bug #36236440)

  • NOT worked correctly with a quantified comparison such as < ALL, > ANY, and so on, but NOT NOT did not. (Bug #115962, Bug #37004689)

  • A GROUP BY query containing a LATERAL subquery raised a spurious Duplicate column error. (Bug #115696, Bug #36885503)

  • 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)

  • Added gcc-toolset-12 to the EL8 and EL9 build specification file to allow building the MySQL 8.0 mysql-community-libs-compat RPM.

    Our thanks to Simon Mudd for the contribution. (Bug #115484, Bug #36796229)

  • Fixed a typo in the Debian package description.

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

  • MYSQL_TYPE_JSON was missing from the description of binary resultsets in the MySQL source code documentation.

    Our thanks to Daniël van Eeden for the contribution. (Bug #115360, Bug #36740656)

  • Certain complex UNION queries triggered an assertion in debug builds, and caused release builds to hang. (Bug #115346, Bug #36739383)

  • A query such as SELECT CASE WHEN 1 THEN NOW() ELSE x.x END FROM (SELECT NULL) x(x) led an assert. This occurred because a generated column description used a temporal type with a fractional seconds precision of 31, which is an invalid precision value. The invalid precision came from type aggregation, where one of the underlying items to the CASE expression was a NULL expression, which has a decimal precision equal 31, meaning an undefined precision.

    The problem is fixed by not aggregating types from expressions that yield NULL.

    This issue did not occur with numeric and string arguments, since they cannot be aggregated directly into a temporal type.

    This issue did not occur with MySQL 8.0 or with MySQL 8.4 release binaries. (Bug #115233, Bug #36705061)

  • A query, which normally used an index range scan, used a less efficient index lookup when run as a prepared statement. (Bug #115227, Bug #36705030)

  • A singly-nested derived table was wrongly merged rather than materialized. (Bug #115215, Bug #36695371)

  • A ROLLUP query did not take account a summary NULL. Consider the following statements: 

    CREATE TABLE t(a INT);
SELECT a, COUNT(*) FROM t GROUP BY a WITH ROLLUP;

    According to the SQL standard, the SELECT statement should be equivalent to a UNION query which produces the result (0, NULL). This is because, even with an empty result set, ROLLUP should give us a single grouping row with NULL entries for all GROUP BY expressions as well as a grand total for any aggregates, in this case 0 for COUNT(*), but MySQL returned an empty set instead.

    Now we return the grouping row in such cases. (Bug #114638, Bug #36514339)

  • Incorrect results were sometimes obtained when using DISTINCT and ORDER BY with a derived table. (Bug #114589, Bug #36496160)

  • A CREATE TABLE statement with a CHECK constraint that involved a CAST with an AT TIME ZONE clause failed with the confusing error Missing time zone function. This was because the text of the CHECK constraint was regenerated internally and subsequently misinterpreted.

    We fix this by ensuring that the correct CHECK constraint text is stored in the data dictionary along with the rest of the CREATE TABLE definition. (Bug #114404, Bug #36423829)

  • 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 join on subqueries which themselves used subqueries in their HAVING and FROM clauses led to an assert in sql/item.h.

    The problem occurred when removing a scalar subquery with a HAVING clause after having decided that the subquery was part of a predicate that could be eliminated. The HAVING clause pointed to an aggregation object (Item_sum_min), indirectly accessed through an Item_aggregate_ref that was added by Item::split_sum_func2(). When removing the subquery, the reference count for the Item_aggregate_ref was decremented without ever having been incremented.

    We fix this by incrementing the object's reference count when it is first created. (Bug #112615, Bug #35877063)

    References: See also: Bug #111492, Bug #35517962.

  • Queries using CASE (WHEN TRUE AND EXISTS (subquery)) did not always return the same result as with CASE (EXISTS (subquery)). (Bug #112557, Bug #35855294)

    References: This issue is a regression of: Bug #32644631, Bug #32802301.

  • A character string literal value selected through a derived table and matched with a column with a different character set through a UNION operation sometimes raised ER_CANT_AGGREGATE_2COLLATIONS (Illegal mix of collations...). (Bug #108627, Bug #34646522)

    References: See also: Bug #36812010, Bug #36844420.

  • 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)

Read the original on dev.mysql.com ↗