[Release Note] MySQL 8.4.4

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

Bugs Fixed

• Bug #36559078 : INSTALL COMPONENT issued concurrently with a SET PERSIST which used a subquery could sometimes lead to an unplanned exit of the server. References: See also: Bug #35647759.

  INSTALL COMPONENT 가 subquery 를 사용한 SET PERSIST 와 동시에 실행될 경우, 가끔 서버가 예기치 않게 종료되는 문제가 발생할 수 있습니다. 참고 자료: 참조: Bug #35647759.

• Bug #36452528 : Incompatible Change: Corruption occurred in a spatial index when an update of a geometry with a minimal change in the minimum bounding rectangle (MBR) was followed by a delete operation. When upgrading to this release, it is recommended that you drop any spatial indexes beforehand, then re-create them after the upgrade is complete. Alternatively, you can drop and re-create such indexes immediately following the upgrade, but before making use of any of the tables in which they occur. You should also be aware that downgrading to any previous version reintroduces the original problem described previously. For more information, see Creating Spatial Indexes.

  호환되지 않는 변경사항: minimum bounding rectangle(MBR) 의 변화가 거의 없는 geometry 데이터를 업데이트 이후 삭제 작업을 수행하면 spatial index 에서 손상이 발생하는 문제가 있습니다. 8.0.41 로 업그레이드할 때에는 먼저 모든 spatial index 를 삭제하고 업그레이드가 완료된 이후에 다시 생성하는 것이 좋습니다. 또는 업그레이드 후 테이블을 사용하기 전에 spatial index 를 삭제하고 다시 생성할 수도 있습니다. 또한, 이전 버전으로 다운그레이드할 경우 이 문제가 다시 발생할 수 있다는 점을 유의해야 합니다. 자세한 내용은 ""Creating Spatial Indexes"" 을 참조하세요.

• Bug #37271715 : InnoDB: Concurrently truncating a table while querying the Performance Schema sometimes cause MySQL to halt unexpectedly.

  InnoDB: Performance Schema 를 조회하는 동안 동시에 테이블을 truncate 하는 경우, MySQL 이 예기치 않게 중단되는 현상이 발생할 수 있습니다.

• Bug #37189985 : InnoDB: It was possible for an ALTER TABLE operation using the INPLACE algorithm on a table containing both a spatial index and an auto-increment column to cause corruption or, in debug builds, to trigger a debug assert. This was due to the auto-increment column value being overwritten in the old records of the spatial index while the new record was prepared.

  InnoDB: spatial index 와 auto-increment 컬럼을 모두 포함된 테이블에서 INPLACE 알고리즘을 사용하여 ALTER TABLE 작업을 수행하는 경우, 손상이 발생하거나 debug 빌드에서 debug assert 이 트리거될 가능성이 있었습니다. 이는 새로운 레코드가 준비되는 동안 spatial index 의 이전 레코드에서 auto-increment 컬럼 값이 덮어써지는 문제 때문이었습니다.

• Bug #115511, Bug #36808088 : InnoDB: It was possible for ALTER TABLE, which rebuilds InnoDB tables using the INPLACE algorithm, to be rejected with a duplicate key error due to a non-duplicate record being inserted concurrently while the rebuild was paused to release a page latch.

  InnoDB: INPLACE 알고리즘을 사용하여 InnoDB 테이블을 재구성하는 ALTER TABLE 작업이 중복 키 오류로 거부될 가능성이 있었습니다. 이는 page latch 를 해제하기 위해 rebuild 가 일시 중지된 동안 non-duplicate 레코드가 동시에 삽입되었기 때문입니다.

• Bug #115457, Bug #36796094 : InnoDB: The check enforcing the rule that ALGORITHM=INSTANT cannot be used on a column referenced by a foreign key constraint from another table did not inspect the last field of said constraint.

  InnoDB: 다른 테이블의 foreign key 제약 조건에 의해 참조되는 컬럼에 ALGORITHM=INSTANT 를 사용할 수 없다는 규칙을 강제하는 검사에서 해당 제약 조건의 마지막 필드를 검사하지 않았습니다.

• Bug #115399, Bug #36765223 : InnoDB: CPU usage statistics did not account for a processor count over 128, which could degrade performance on these larger systems.

  InnoDB: CPU 사용량 통계가 128개를 초과하는 프로세서 수를 고려하지 않아, 이러한 대규모 시스템에서 성능 저하가 발생할 수 있었습니다.

• Bug #110706, Bug #113812, Bug #115608, Bug #116764, Bug #36765223, Bug #36261480, Bug #36846567, Bug #37318367 : InnoDB: An ALTER TABLE operation that rebuilt an InnoDB table using the INPLACE algorithm potentially led to losing a row of data if a purge occurred concurrently on the altered table that contained a clustered or spatial index.

  InnoDB: 테이블에 clustered 또는 spatial index 가 포함되어 있는 테이블에 INPLACE 알고리즘을 사용하여 InnoDB 테이블을 rebuild 하는 ALTER TABLE 작업을 하는동안 동시에 purge 작업이 발생하면 데이터 row 가 손실될 가능성이 있었습니다.

• Bug #115399, Bug #37008345 : Replication: While large transactions were being received and applied, and a request to stop the replication channel was made using STOP REPLICA, MySQL did not do so properly, and subsequently did not process any channel commands. In addition, the server shutdown process did not complete gracefully, and required either the MySQL process to be killed or the host system to be restarted.

  Replication: 큰 트랜잭션이 수신 및 적용되는 동안 STOP REPLICA 명령을 사용하여 복제 채널 중지를 요청하면, MySQL 이 제대로 중지하지 못하는 문제가 발생했습니다. 이로 인해 이후 어떤 채널 명령도 처리되지 않으며, 서버 종료 과정도 정상적으로 완료되지 않고, MySQL 프로세스를 강제로 종료하거나 호스트 시스템을 재시작해야 하는 상황이 발생할 수 있었습니다.

• Bug #116334, Bug #37161583 : Incorrect results were returned by some queries that used hash antijoins when the hash table did not fit in the join buffer and spilled to disk. (The query triggering the issue actually specified LEFT JOIN, but this was transformed internally from a left outer join to an antijoin.) The problem was that some rows in the probe table were skipped when writing the probe rows to chunk files, the skipped rows being those that had NULL in part of the join key. Such rows can be skipped for inner joins and semijoins, as they are known to have no match in the build table, but for outer joins and antijoins, rows in the probe table which have no matching row in the build table should be part of the join result, so they must be included in the chunk files. We already preserved these rows in the chunk files for outer joins. This fix extends the logic used for that purpose so that it also applies for antijoins.

  hash antijoin 을 사용하는 일부 쿼리에서 join buffer 에 맞지 않는 hash table 이 디스크로 넘쳐서(spilled) 잘못된 결과가 반환되는 문제가 있었습니다. (실제로 문제를 일으킨 쿼리는 LEFT JOIN 을 지정했지만, 내부적으로는 left outer join 이 antijoin 으로 변환되었습니다.) 문제는 probe table 의 일부 row 가 join key 의 일부에 NULL 이 있을 때 chunk files 에 probe row 를 쓸 때 누락되었다는 점입니다. 이러한 row 는 inner join 과 semijoin 에서는 건너뛸 수 있습니다. 왜냐하면 build table 에 일치하는 값이 없다고 알려져 있기 때문입니다. 그러나 outer join 과 antijoin 에서는 build table 에 일치하는 row 가 없는 probe table 의 row 도 join 결과의 일부여야 하므로, 해당 row 는 chunk files 에 포함되어야 합니다. 우리는 이미 outer join 의 경우 이러한 row 을 chunk files 에 보존하고 있습니다. 이번 수정은 해당 용도로 사용된 로직을 확장하여 antijoins 에도 적용되도록 했습니다.

• Bug #112362, Bug #35842412 : In MySQL 8.0 and later, queries of the form SELECT DISTINCT … FROM t1 WHERE NOT IN(SELECT …) were transformed into an antijoin if possible, causing the optimizer not to choose a group skip scan for table t1 whereas it would have been chosen in MySQL 5.7. This resulted in a performance degradation for such queries. Group skip scan is not chosen, since the query is now no longer a single-table query following the antijoin transformation, and this access method is enabled only for single table queries. The same behaviour can be seen for queries which are transformed into semijoins as well. In such cases, group skip scan access method can still be used if the access method is used only for duplicate removal (that is, with DISTINCT or GROUP BY, but without aggregate functions). To fix this, we enable group skip scan when there is only one table in the original query, irrespective of the number of semijoin tables present after internal transformations as long as the query contains no aggregate functions.

  MySQL 8.0 및 그 이후 버전에서는 가능하면 SELECT DISCT ... FROM t1 WHERE NOT IN (SELECT ...) 형식의 쿼리가 antijoins 으로 변환되어 옵티마이저가 테이블 t1 에 대해 group skip scan 을 선택하지 않게 되었습니다. 이로 인해 쿼리의 성능이 저하되었습니다. 쿼리는 antijoins 변환을 거친 후 더 이상 단일 테이블 쿼리가 아니기에, group skip scan 이 선택되지 않았고, 이 접근 방식은 단일 테이블 쿼리에서만 활성화되었습니다. semi-join 으로 변환된 쿼리에서도 동일한 동작을 볼 수 있습니다. 이러한 경우 액세스 방법이 중복 제거(즉, DISTCT 또는 GROUP BY 는 포함되지만 집계 함수는 포함되지 않음)에만 사용되는 경우에도 group skip scan 으로 접근 방법을 계속 사용할 수 있습니다. 이 문제를 해결하기 위해, 원본 쿼리에 단일 테이블만 있고 내부 변환 후 semi-join 테이블이 몇 개 있더라도 쿼리에 집계 함수가 포함되지 않은 경우 group skip scan 을 활성화합니다.