[Release Note] MySQL 8.4.5

Changes in MySQL 8.4.5 (2025-04-15, LTS Release)

Bugs Fixed

• Bug #36890891 : Important Change: When an SQL function is improved from one release to the next, it may throw SQL errors in situations in which it previously did not. If this happens in a table’s constraints, default expressions, partitioning expressions, or virtual columns, the table could not be opened. This prevented both analyzing the problem (using, for example, SHOW CREATE TABLE) and addressing it (such as with an ALTER TABLE … DROP … statement).
  Now, on server upgrade, we scan the data dictionary for tables that use any of the features just mentioned. We then try to open such tables, and if we fail to do so, we alert the user. This patch addresses this. The –check-table-functions server option introduced in this release helps to address this problem by making it possible to specify the server’s behavior when encountering an error with such a function. Set this option to WARN in order to log a warning for each table which the server could not open; setting it to ABORT also logs these warnings as WARN, but aborts the server upgrade if any issues were found.
  ABORT is the default; this enables the user to fix the issue using the older version of the server before upgrading to the new one. WARN flags the issues, but allows the user to continue in interactive mode while addressing the problem. (Bug #36890891)
  References: See also: Bug #37009318. This issue is a regression of: Bug #98950, Bug #98951, Bug #31031886, Bug #31031888.

  Important Change : SQL 함수가 릴리스마다 개선되면 이전에는 발생하지 않았던 상황에서 SQL 오류가 발생할 수 있습니다. 이러한 문제가 테이블의 제약 조건, default 표현식, partitioning 표현식 또는 virtual columns 에서 발생하면 테이블을 열 수 없습니다. 이로 인해 문제 분석(예:SHOW CREATE TABLE)과 해결(예: ALTER TABLE ... DROP ...명령문)이 모두 불가능했습니다. 이제 서버 업그레이드 시, data dictionary 를 검사하여 앞서 언급한 기능을 사용하는 테이블을 확인합니다. 이후 해당 테이블을 열려고 시도하고, 실패할 경우 사용자에게 경고합니다. 이 패치는 해당 문제를 해결합니다. 이번 릴리스에서 도입된 --check-table-functions 서버 옵션을 사용하면, 함수 관련 오류 발생 시 서버의 동작을 지정할 수 있습니다. WARN 으로 설정하면 서버가 열지 못한 테이블마다 경고를 기록하지만, 업그레이드를 계속 진행할 수 있습니다. ABORT 로 설정하면 동일한 경고를 기록하지만, 문제가 발견될 경우 서버 업그레이드를 중단합니다. 기본값은 ABORT로, 사용자가 이전 버전의 서버를 사용해 문제를 해결한 후 새 버전으로 업그레이드할 수 있도록 합니다. WARN 은 문제를 알려주지만 대화형 모드에서 계속 진행할 수 있도록 합니다. References : Bug #37009318도 참조하세요. 이 문제는 Bug #98950, Bug #98951, Bug #31031886, Bug #31031888 의 회귀입니다.

• Bug #36778475 : Fixed a performance issue in the PROCESSLIST table.

  PROCESSLIST 테이블의 성능 문제를 수정했습니다.

• Bug #37292404 : InnoDB: Fixed an issue relating to pessimistic row update.

  InnoDB: pessimistic row update(비관적인 행 업데이트) 와 관련된 문제가 해결되었습니다.

• Bug #37286473 : InnoDB: The CHECK TABLE operation could incorrectly report corruption in spatial indexes.

  InnoDB: CHECK TABLE 작업이 spatial index 의 손상을 잘못 보고할 수 있습니다.

• Bug #37061960 : InnoDB: Fixed an issue relating to InnoDB redo log recovery.

  InnoDB: InnoDB redo log recovery 와 관련된 문제를 수정했습니다.

• Bug #32288105 : InnoDB: Fixed an issue relating to lower_case_table_names.

  InnoDB: lower_case_table_names 와 관련된 문제를 수정했습니다.

• Bug #117459, Bug #37617773 : InnoDB: Partition table indexes were not checked when retrieving a record count while that table’s definition was being altered by another client session. The record count was executed without error.
  As of this release, the index is checked to ensure it is usable when retrieving a record count.

  InnoDB : 다른 클라이언트 세션에서 테이블 정의가 변경되는 동안 레코드 카운트를 가져올 때, partition table 인덱스가 확인되지 않았습니다. 레코드 카운트는 오류 없이 실행되었습니다. 이번 릴리스부터 레코드 카운트를 검색할 때 인덱스를 사용할 수 있는지 확인하기 위해 인덱스가 검사됩니다.

• Bug #116463, Bug #37212019 : InnoDB: Changes made to innodb_spin_wait_delay in MySQL 8.0.30 negatively impacted performance.

  InnoDB: MySQL 8.0.30 에서 innodb_spin_wait_delay 로 변경된 사항은 성능에 부정적인 영향을 미쳤습니다.

• Bug #116353, Bug #37168132 InnoDB: Under certain circumstances, using ALTER TABLE with INPLACE to modify the size of a column could result in an index which exceeds the valid size limit (767 bytes). This occurred for tables with a row format of Redundant or Compact and the row format was not explicitly defined in the table creation.
  As of this release, a validation is performed and an error returned by any ALTER TABLE, INPLACE operation which will result in an invalid index size.

  InnoDB : 특정 상황에서 ALTER TABLE 명령어를 INPLACE 방식으로 사용하여 컬럼 크기를 변경하면, 인덱스 크기가 유효한 한도(767bytes)를 초과하는 문제가 발생할 수 있었습니다. 이 문제는 테이블 생성 시 row format 을 명시하지 않고 생성된 Redundant 또는 Compact 형식의 테이블에서 발생했습니다. 이번 릴리스부터는 유효하지 않은 인덱스 크기를 초래하는 ALTER TABLE INPLACE 작업에 대해 검증이 수행되며, 해당 작업은 오류를 반환하게 됩니다.

• Bug #107991, Bug #34454572 : InnoDB: Fixed a memory leak in the Clone_persist_gtid thread.

  InnoDB: Clone_perist_gtid thread 에서 memory leak 을 수정했습니다.

• Bug #37397306 : Partitioning: When inserting NOW() into a column not part of the partition key of a partitioned table, all partitions were retrived, and no pruning occurred.

  Partitioning : partitioned table 에서 partition key 에 포함되지 않은 컬럼에 NOW() 를 삽입할 때, 모든 partition 이 조회되었으며 partition pruning 이 발생하지 않았습니다.

• Bug #37462058 : Replication: In a source-replica setup, the replica encountered irregular failures of UPDATE and DELETE statements with ER_KEY_NOT_FOUND errors on the same table. (The replica’s binary log and GTID records showed that the row required was committed, and had not been deleted or updated.) This occurred on the replica when the row-matching algorithm used was HASH_SCAN and two rows in the same table had the same CRC32 value.
  In the event of such a CRC32 collision, finding a matching CRC32 in the hash table does not guarantee that the correct row is being updated, so the algorithm iterates over any multiple entries having the same CRC32, and compares the full record for each of them in a loop; the problem occurred due to the fact that the logic to exit this loop was incorrect. This logic has now been corrected.

  Replication : Source-Replica 구성에서, Replica 는 동일한 테이블에 대해 UPDATE 및 DELETE 문이 ER_KEY_NOT_FOUND 오류와 함께 비정기적으로 실패하는 현상을 겪었습니다. (Replica 의 binlog 와 GTID 기록에는 해당 row 가 commit 되었으며 삭제되거나 수정되지 않았음이 나타나 있었습니다.) 이 문제는 Replica 에서 HASH_SCAN 알고리즘을 사용하고 동일한 테이블 내 두 row 가 동일한 CRC32 값을 가질 때 발생했습니다. 이러한 CRC32 충돌이 발생할 경우, hash table 에서 일치하는 CRC32 값을 찾았다고 해서 반드시 올바른 row 를 찾았다고 보장할 수 없기 때문에, 알고리즘은 동일한 CRC32 값을 가진 여러 엔트리를 반복하면서 각 레코드를 전체 비교하게 됩니다. 문제는 이 반복 루프를 빠져나오는 로직이 잘못되어 있었기 때문에 발생했습니다. 현재 로직은 올바르게 수정되었습니다.

• Bug #36479088 : Replication: The asynchronous_connection_failover_delete_source() function did not always perform as expected in all cases

  Replication: asynchronous_connection_failover_delete_source() 함수가 예상대로 작동하지 않았습니다.

• Bug #36479083 : Replication: In some cases, the asynchronous_connection_failover_add_source() function did not perform as expected.

  Replication: 일부 경우에는 asynchronous_connection_failover_add_source() 함수가 예상대로 작동하지 않았습니다.

• Bug #102175, Bug #32442772 : Replication: When the server was under a heavy write load, the binary log position for gtid_executed as shown in the Performance Schema log_status table did not match that of the gtid shown in the binary log file.
  We fix this by increasing the scope of the lock on the log_status table when querying it to ensure that transactions in the commit pipeline are completed. This ensures that a query against the log_status table waits until gtid_executed has been fully updated, thereby guaranteeing consistency with its position in the binary log.

  Replication: 서버에 쓰기 부하가 많을 때, Performance Schema 의 log_status 테이블에 표시되는 gtid_executed 의 binlog 위치가 실제 binlog 파일에 기록된 GTID 위치와 일치하지 않는 문제가 있었습니다. 이 문제는 log_status 테이블을 조회할 때 잠금(lock)의 범위를 넓혀서, commit 파이프라인에 있는 트랜잭션들이 모두 완료된 이후에만 결과를 반환하도록 수정하여 해결했습니다. 이렇게 함으로써 log_status 테이블을 조회할 때 gtid_executed 가 완전히 반영될 때까지 기다리게 되어, binlog 와의 일관성이 보장됩니다.

• Bug #117085, Bug #37436310 : A negative impact in performance was observed when using a multivalued index with ORDER BY DESC and LIMIT in a query, where the value specified by LIMIT was greater than the number of rows actually in the result. References: This issue is a regression of: Bug #104897, Bug #33334911.

  ORDER BY DESC 와 LIMIT 을 함께 사용하는 쿼리에서, 실제 결과 row 수보다 LIMIT 값이 더 클 경우, multivalued index 를 사용할 때 성능이 저하되는 현상이 관찰되었습니다. 참조: 이 문제는 다음과 같은 회귀 분석입니다: Bug #104897, Bug #33334911.

• Bug #115706, Bug #36892499 : If one client session had a uncommitted transaction that caused a DROP TABLE statement in another client session to be blocked, a third client session hung when trying to issue a USE DATABASE statement.

  어떤 클라이언트 세션에서 commit 되지 않은 트랜잭션이 실행 중이고, 이로 인해 다른 클라이언트 세션에서 실행한 DROP TABLE 명령이 대기 상태에 빠졌을 경우, 세 번째 클라이언트 세션이 USE DATABASE 문을 실행하면 해당 세션도 멈추는(hang) 문제가 발생했습니다.