[Release Note] MySQL 8.0.40

Changes in MySQL 8.0.40 (2025-01-21, LTS Release)

Bugs Fixed

• Bug #111538, Bug #35531293 : 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. References: This issue is a regression of: Bug #81814, Bug #16739204, Bug #23584861.

  Performance; InnoDB: MySQL 8.0.28 에서 inline 으로 정의된 여러 InnoDB 내부 함수들이 MySQL 8.0.33 에서는 더 이상 inline 으로 정의되지 않았습니다. 이는 InnoDB adaptive hash index 를 개선하기 위해 MySQL 8.0.30 에서 수행된 refactoring 의 일부로 발생한 문제입니다. 이로 인해 InnoDB 테이블에서 조인을 사용하는 쿼리에 부정적인 영향을 미쳤습니다. 참조: 이 문제는 다음과 같은 회귀 입니다. Bug #81814, Bug #16739204, Bug #23584861.

• Bug #115229, Bug #36705034 : 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.

  InnoDB: 시스템이 FusionIO 에 대해 다른 섹터 크기를 지원하는지 확인할 때 초기화되지 않은 버퍼가 임시 파일에 기록되고 있었습니다.이 확인은 innodb_flush_method 가 O_DIRECT 또는 O_DIRECT_NO_FSYNC 로 설정되어 있을 때 이루어집니다.

• Bug #114465, Bug #36444172 : 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.

  InnoDB: secondary 인덱스가 포함된 테이블 rebuild 작업은 MySQL 8.0.26 에 비해 InnoDB 임시파일에 더 많은 파일 I/O 를 요구하여 쿼리 성능을 저하시켰습니다.

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

  InnoDB: Performance Schema 가 활성화되어 있을 때 Alter_stage 클래스의 문제로 인해 parallel index builder 를 사용하여 인덱스를 추가하는 속도가 훨씬 느려졌습니다.

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

  Group Replication: xcom\network\xcom_network_provider_native_lib.cc 에서 잠재적인 메모리 누수를 제거했습니다.

• Bug #115535, Bug #36934913 : 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.

  SLES 15 대상 플랫폼이 오픈소스 15.5 에서 15.6으로 변경되었으며, 이는 GCC 12 대신 GCC 13을 사용하고 OpenSSL 1.1.x 대신 시스템의 OpenSSL 3.x 를 기준으로 빌드한다는 의미이기도 합니다.

• Bug #113699, Bug #36213938 : 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.

  prefer_ordering_index=off 를 사용하면 참조키가 없는 쿼리가 정렬을 피할 수 있어야 하는데도 full table 을 스캔하고 정렬하는 것으로 되돌아갔습니다. 기여해 주신 Daniel Nichter에게 감사드립니다.

• Bug #112035, Bug #113761, Bug #36302624, Bug #36015586, Bug #36690035, Bug #35712638, Bug #36891888 : 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.

  performance schema 의 data_locks 및 data_lock_waits 테이블이 재설계되어 트랜잭션 또는 잠금 시스템에 대한 독점적인 글로벌 뮤텍스가 필요하지 않게 되었습니다. 이전에는 트랜잭션에 대해 반복 처리했다면, 이제는 잠금을 보관하는 해시 테이블 버킷을 반복 처리하여 활성 처리된 샤드에 대해서만 잠급니다. 또한 속도와 메모리 측면에서 반복 로직의 복잡성을 개선하여 이러한 쿼리가 나머지 시스템에 미치는 영향을 줄입니다. 쿼리 결과는 두 개의 버킷을 방문하는 동안 트랜잭션이 커밋되거나 시작되거나 소유한 잠금 집합이 변경된 경우 불완전한 트랜잭션 잠금 목록을 보여줄 수 있습니다. 이는 이전 동작과 다르며, 이전 동작은 항상 개별 트랜잭션이 보유한 잠금의 일관된 스냅샷을 표시했지만, 두 개의 서로 다른 트랜잭션이 서로 다른 순간에 표시될 수 있었습니다. 즉, 새로운 접근 방식은 대기 잠금을 포함하여 충돌하는 잠금을 보여주기 위해 항상 같은 버킷에 있는 단일 대기 큐의 일관된 보기를 제공합니다. 반면, 이전 접근 방식은 충돌하는 잠금이 다른 트랜잭션에 속하더라도 일부를 놓칠 수 있었습니다. 이전 접근 방식은 보고된 트랜잭션이 보유한 다른 모든 잠금을 항상 표시했지만, 다른 트랜잭션의 잠금을 놓칠 수 있었습니다.

• Bug #104897, Bug #33334911 : 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.

  multi-valued index 를 사용하는 쿼리에서 부등호(>) 또는 미만(<) 비교를 사용하는 경우, 동일한 인덱스를 사용하는 동등(=) 비교를 사용하는 쿼리보다 훨씬 느리게 실행되었습니다.

• Bug #100537, Bug #31763497 : 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.

  부하가 큰 인스턴스에서 SELECT * FROM sys.innodb_lock_waits;를 실행하면 서버 성능에 영향을 미쳤습니다. 이번 릴리스부터 SELECT * FROM sys.innodb_lock_waits; 는 각 대기마다 두 개의 잠금만 가져오고, 각 대기에 대해 모든 잠금을 두 번 스캔하는 대신 성능을 개선했습니다. 이 수정의 일환으로 DATA_LOCKS 및 DATA_LOCK_WAITS 에 primary key 가 추가되었습니다.