---
title: "MySQL 8.0.41 릴리스 노트"
description: "MySQL 8.0.41 Community Server 릴리스 노트를 한국어로 번역하고, DBA가 참고해야 할 핵심 내용을 함께 정리하였습니다."
tags: [ MySQL, 릴리스노트 ]
image: "mysql-release-note.png"
author: "Oracle"
published: "2025-01-21"
updated: ""
source_url: "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-41.html"
---

## DBA를 위한 핵심 내용

MySQL 8.0.41은 공간 인덱스를 사용하는 환경에서는 반드시 별도로 검토해야 하는 릴리스입니다. 릴리스노트에 명시된 “호환되지 않는 변경 사항”으로, geometry의 minimum bounding rectangle(MBR)에 작은 변경이 발생한 뒤 삭제 작업이 이어질 때 공간 인덱스 손상이 발생할 수 있으며, 업그레이드 전후 공간 인덱스를 삭제하고 다시 생성하는 절차가 권장됩니다.

1. 공간 인덱스가 있는 테이블은 업그레이드 전에 모든 공간 인덱스를 삭제한 뒤 업그레이드 후 재생성하거나, 업그레이드 직후 해당 테이블을 사용하기 전에 삭제·재생성하는 절차를 준비해야 합니다. 이는 일반적인 “확인 권장” 수준이 아니라 릴리스노트가 직접 권고하는 조치입니다.
2. InnoDB에서는 공간 인덱스와 `AUTO_INCREMENT` 컬럼이 함께 있는 테이블에서 `INPLACE` `ALTER TABLE`이 손상을 유발할 수 있던 문제, Performance Schema 조회와 동시 truncate 중 서버 중단, full-text 인덱스와 자기 참조 외래 키 관련 assertion 등 운영 중 크래시·손상 계열 수정이 많습니다.
3. Group Replication에서는 primary가 예기치 않게 그룹을 떠난 뒤 빠르게 재조인하는 상황, 새 secondary 추가 후 쓰기 불능 상태가 지속되는 교착 상태, `replica_preserve_commit_order` 보장의 예외 처리 등 HA 운영에 영향을 주는 항목이 포함되어 있습니다. InnoDB Cluster를 쓰는 환경에서는 롤링 업그레이드와 멤버 추가/제거 테스트가 필요합니다.
4. Optimizer/SQL 처리 측면에서는 캐릭터셋이 다른 뷰에서 조건 pushdown 시 결과 로우가 사라지는 문제, aggregate 조건 pushdown, hash anti join의 잘못된 결과 가능성 등 결과 정확성과 관련된 항목이 있습니다. 특정 쿼리 패턴을 많이 쓰는 서비스는 대표 쿼리 결과 비교를 수행하는 것이 좋습니다.
5. Enterprise Firewall 저장 프로시저가 업그레이드 후 올바르게 처리되지 않는 경우가 수정되었습니다. Enterprise Firewall을 사용하는 환경에서는 업그레이드 후 방화벽 프로시저와 정책 적용 상태를 확인해야 합니다.
6. 웹 검색에서는 8.0.41에 대해 Fedora 보안/중요 업데이트 알림과 FreeBSD 포트 업데이트가 확인되지만, 공식 릴리스노트 밖에서 이 버전 전용으로 널리 알려진 별도 회귀 이슈는 확인하지 못했습니다. 따라서 이 버전은 외부 보고보다 공식 문서의 공간 인덱스 재생성 권고와 Group Replication 수정에 무게를 두는 것이 맞습니다.

## 계정 관리 관련 사항

- [`DROP USER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/drop-user.html) 실행 후 데이터베이스 캐시가 올바르게 플러시되지 않았습니다. (Bug #37132323)
- 실패한 비밀번호 검증이 항상 올바르게 처리되지는 않았습니다. (Bug #37041439)

## 캐릭터셋 지원

- 연결 및 클라이언트 캐릭터셋을 `latin1`로 사용하여 생성된 뷰에서 선택할 때, 뷰에 대한 쿼리가 연결 및 클라이언트 캐릭터셋으로 `utf8`을 사용하고, 뷰에 ASCII가 아닌 문자가 포함된 리터럴 값이 포함되어 있으며, 쿼리가 뷰의 쿼리 블록에 대한 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html) 안으로 조건 푸시다운을 수행한 경우, 하나의 로우가 예상되었지만 로우가 0개 반환되었습니다.

  이 문제는 유사한 문제의 오류를 수정한 이전 문제와 관련이 있었습니다: 해당 경우의 문제는 뷰에 포함된 조건을 내부 쿼리 블록으로 푸시다운할 때 뷰 정의의 캐릭터셋을 적절히 고려하는 것이었지만, 당시 구현된 수정에서는 뷰에 ASCII가 아닌 문자가 포함될 가능성을 고려하지 않았습니다.

  이는 푸시다운할 조건이 잘못된 캐릭터셋의 텍스트 문자열에 기록되었음을 의미했습니다. 문자열이 올바른 캐릭터셋으로 생성되도록 보장하여 이 누락을 수정했습니다. (Bug #37111452)

  참조: 다음도 참조하십시오: Bug #36246859.

## 컴파일 관련 사항

- **macOS:** MacOS 빌드에서 사용되지 않는 CMake 코드를 제거했습니다. (Bug #37258036)
- **macOS:** ld: warning: ignoring duplicate libraries 형식의 경고와 `xcodebuild`에 특정한 경고를 제거했습니다. (Bug #37065301)
- **Solaris:** Solaris에서 MySQL을 빌드하는 데 필요한 GCC의 최소 버전이 11.4로 상향되었습니다. 자세한 내용은 [Source Installation Prerequisites](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/source-installation-prerequisites.html)를 참조하십시오. (Bug #37256600)
- CMake 3.26부터 CMake는 `CMakeError.log`를 대체하는 파일 `CMakeFiles/CMakeConfigureLog.yaml`을 작성합니다. 따라서 `CMakeError.log`에 대한 참조가 제거되었습니다. (Bug #37305289)
- MySQL을 컴파일하는 데 사용되는 `libedit` 버전이 20240808-3.1로 업그레이드되었습니다. (Bug #37101293)
- XCode 16으로 MySQL을 컴파일할 때 발견된 `mysql_prepare_create_table()`의 오류(`sql/sql_table.cc` 파일 내)를 제거했습니다. (Bug #37068527)
- TIRPC 관련 문제로 인해 cmake 3.11을 사용하여 Fedora 40(및 다른 Linux 플랫폼일 가능성이 있음)에서 서버를 빌드할 수 없었습니다. (Bug #116164, Bug #37080195)

## 컴포넌트 관련 사항

- 하위 쿼리를 사용한 [`SET PERSIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set.html)와 동시에 실행된 [`INSTALL COMPONENT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/install-component.html)는 때때로 서버의 예기치 않은 종료로 이어질 수 있었습니다. (Bug #36559078)

  참조: 함께 참조하십시오: Bug #35647759.

## Firewall 관련 사항

- 일부 경우에는 업그레이드를 수행한 후 MySQL Enterprise Firewall과 관련된 저장 프로시저가 올바르게 처리되지 않았습니다. (Bug #36084822)

## Optimizer 관련 사항

- `WHERE` 절에 있는 집계 함수를 포함한 조건을 푸시다운하면, 평가되어서는 안 될 때 집계 함수가 평가되었습니다. (Bug #36421735)

## Performance Schema 관련 사항

- root가 아닌 사용자가 [`START REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/start-replica.html)를 실행한 경우, [`PERFORMANCE_SCHEMA.PROCESSLIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-processlist-table.html)는 새로 생성된 foreground 복제 스레드에 `system user` 대신 해당 사용자의 이름을 할당했습니다.

  이 릴리스부터는 모든 foreground 시스템 스레드에 `system user`가 할당됩니다. (Bug #37357562)
- 특정 상황에서 메타데이터 잠금은 다른 `LOCK_TYPE`으로 업그레이드되거나 다운그레이드될 수 있습니다. 이 변경 사항은 [`PERFORMANCE_SCHEMA.METADATA_LOCKS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-metadata-locks-table.html) 테이블에 반영되지 않았습니다.

  기여해 주신 George Ma와 Alibaba 팀에 감사드립니다. (Bug #116625, Bug #37271768)

## 추가되거나 변경된 기능

- 시스템 `curl` 라이브러리에 링크하지 않고 `curl`을 포함하는 바이너리 패키지는 `curl` 8.11.1을 사용하도록 업그레이드되었습니다. (Bug #37389565)

## 수정된 버그

- **호환되지 않는 변경 사항:** minimum bounding rectangle (MBR)에 최소한의 변경이 있는 geometry의 업데이트 뒤에 삭제 작업이 수행되면 공간 인덱스에서 손상이 발생했습니다.

  이 릴리스로 업그레이드할 때는 사전에 모든 공간 인덱스를 삭제한 다음, 업그레이드가 완료된 후 다시 생성하는 것이 좋습니다. 또는 업그레이드 직후, 그러나 해당 인덱스가 있는 테이블을 사용하기 전에 이러한 인덱스를 삭제하고 다시 생성할 수 있습니다. 또한 이전 버전으로 다운그레이드하면 앞에서 설명한 원래 문제가 다시 발생한다는 점도 알고 있어야 합니다.

  자세한 내용은 [Creating Spatial Indexes](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/creating-spatial-indexes.html)를 참조하십시오. (Bug #36452528)
- **InnoDB:** Performance Schema를 쿼리하는 동안 동시에 테이블을 truncate하면 MySQL이 예기치 않게 중단되는 경우가 있었습니다. (Bug #37271715)
- **InnoDB:** 공간 인덱스와 자동 증가 컬럼을 모두 포함하는 테이블에서 `INPLACE` 알고리즘을 사용하는 `ALTER TABLE` 작업이 손상을 일으키거나, debug 빌드에서는 debug assert를 트리거할 수 있었습니다. 이는 새 레코드가 준비되는 동안 공간 인덱스의 기존 레코드에서 자동 증가 컬럼 값이 덮어써졌기 때문입니다. (Bug #37189985)

- **InnoDB:** 특정 IO 버퍼 직렬화가 디버그 빌드에서 어설션을 트리거하여 시스템이 중단되었습니다. (Bug #37139618)
- **InnoDB:** `InnoDB` 시작 시간이 개선되었습니다. (Bug #36880863)

  참조: 이 문제는 다음의 회귀입니다: Bug #36808732.
- **InnoDB:** 4294967295보다 큰 `FTS_DOC_ID` 값을 가진 테이블에 `FULLTEXT` 인덱스를 생성할 때 어설션 실패가 발생했습니다. (Bug #36879147)

  참조: 다음도 참조하십시오: Bug #37387224.
- **InnoDB:** 기본 키를 삭제한 다음, `INPLACE` 알고리즘을 사용하여 새 `AUTO_INCREMENT` 컬럼을 내림차순의 기본 키로 추가하는 작업이 실패했습니다.

  기여해 주신 Alibaba의 Shaohua Wang 및 팀에 감사드립니다. (Bug #36658450)
- **InnoDB:** 사용자 테이블스페이스를 확장하면 파일 확장 redo 로그 레코드(`MLOG_FILE_EXTEND`)가 생성되지만, 시스템 테이블스페이스를 확장할 때는 생성되지 않았습니다. (Bug #36511673)
- **InnoDB:** 자기 참조 외래 키와 full-text 인덱스가 있는 테이블에 대한 `DELETE` 작업이 어설션을 트리거할 수 있었습니다. (Bug #36234681)
- **InnoDB:** 모든 버퍼 풀 페이지에서 AHI 인덱스를 지울 때, 블록 mutex를 획득하기 전에 블록 상태가 BUF_BLOCK_MEMORY로 변경될 가능성이 있어 예기치 않은 중단이 발생했습니다. (Bug #35037114)

- **InnoDB:** redo log 삽입(`MLOG_REC_INSERT`)에 대한 공통 접두사 압축은 비활성화되어 있었지만, 이제 버전이 일치하면 활성화됩니다. (Bug #34946626)

  참조: 이 문제는 다음 버그의 회귀입니다: Bug #13899.
- **InnoDB:** 외부에 저장된 [`BLOB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/blob.html)을 포함하는 로우의 가상 컬럼 정보가 `UPDATE` 작업 중 항상 로그에 기록되지는 않았으며, 이로 인해 때때로 Index PRIMARY is corrupted 오류가 발생했습니다. (Bug #34574604)
- **InnoDB:** secondary 인덱스를 포함하는 generated 컬럼에 대한 `ON DELETE CASCADE`가 삭제 전에 가상 컬럼 템플릿이 초기화되지 않아 때때로 실패했습니다.

  이 기여를 해 주신 Rahul Malik에게 감사드립니다. (Bug #33691659)
- **InnoDB:** 업데이트 작업이 자식 테이블의 업데이트 노드를 빌드하는 동안 가상 컬럼을 업데이트하려고 시도했지만, 외래 키 제약 조건은 가상 컬럼을 참조할 수 없으므로 그렇게 해서는 안 되었습니다. (Bug #33327093)
- **InnoDB:** `INPLACE` 알고리즘을 사용하여 `InnoDB` 테이블을 다시 빌드하는 `ALTER TABLE`이, 페이지 래치를 해제하기 위해 다시 빌드가 일시 중지된 동안 중복되지 않는 레코드가 동시에 삽입되어 중복 키 오류로 거부될 수 있었습니다.

  이 수정에 기여해 주신 Dmitry Lenev와 Percona 팀에 감사드립니다. (Bug #115511, Bug #36808088)

- **InnoDB:** `ALGORITHM=INSTANT`는 다른 테이블의 외래 키 제약 조건에서 참조하는 컬럼에 사용할 수 없다는 규칙을 적용하는 검사가 해당 제약 조건의 마지막 필드를 검사하지 않았습니다. (Bug #115457, Bug #36796094)
- **InnoDB:** CPU 사용량 통계가 128을 초과하는 프로세서 수를 반영하지 않아, 이러한 대규모 시스템에서 성능이 저하될 수 있었습니다. (Bug #115399, Bug #36765223)
- **InnoDB:** 빈 테이블에 대해 `ADD COLUMN` 또는 `DROP COLUMN`과 함께 `ALTER TABLE`을 실행하면 이제 기본적으로 `INSTANT` 대신 `INPLACE` 알고리즘을 사용합니다. 이 변경으로 인해 이러한 단순한 작업에서는 로우 버전이 더 이상 증가하지 않습니다. (Bug #113051, Bug #36004394)
- **InnoDB:** `INPLACE` 알고리즘을 사용하여 `InnoDB` 테이블을 다시 빌드하는 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 작업은, 변경된 테이블에 클러스터형 인덱스 또는 공간 인덱스가 포함되어 있고 해당 테이블에서 purge가 동시에 발생하는 경우 데이터 로우 하나가 손실될 수 있었습니다.

  이 수정에 기여해 주신 Dmitry Lenev와 Percona 팀에 감사드립니다. (Bug #110706, Bug #113812, Bug #115608, Bug #116764, Bug #35303494, Bug #36261480, Bug #36846567, Bug #37318367)
- **InnoDB:** 내림차순 프라이머리 키와 `index_merge` 최적화를 사용하는 쿼리가 때때로 누락된 로우와 같은 잘못된 결과를 생성했습니다. (Bug #106207, Bug #33767814)

- **Replication:** InnoDB ClusterSet 설정에서 클러스터의 모든 노드에서 [`autocommit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_autocommit)이 `OFF`로 설정된 경우, MySQL Shell을 사용하는 제어된 전환이 Error 1105 (Unknown error)와 함께 거부되었습니다.

  이를 수정하기 위해, `autocommit=OFF`일 때마다 이제 `channel_change_source_connection_auto_failover()`에서 새 트랜잭션을 강제로 시작하여 `SOURCE_CONNECTION_AUTO_FAILOVER`를 변경한 후 정보 저장소 트랜잭션이 실행될 때 테이블 액세스 데드락이 발생하지 않도록 합니다. (Bug #37173907)
- **Replication:** 대규모 트랜잭션이 수신되고 적용되는 동안 [`STOP REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/stop-replica.html)를 사용하여 복제 채널을 중지하라는 요청이 이루어진 경우, MySQL이 이를 제대로 수행하지 않았으며 이후 어떠한 채널 명령도 처리하지 않았습니다. 또한 서버 종료 프로세스가 정상적으로 완료되지 않았으며, MySQL 프로세스를 kill하거나 호스트 시스템을 재시작해야 했습니다. (Bug #115966, Bug #37008345)

- **Replication:** 복제본이 소스에 다시 연결될 때(예를 들어 [`STOP REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/stop-replica.html)를 실행한 뒤 [`START REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/start-replica.html)를 실행하여 중지했다가 다시 시작하는 경우) 작성되는 로그 메시지 `While initializing dump thread for replica with UUID uuid, found a zombie dump thread with the same UUID. Source is killing the zombie dump thread(thread_id)`가 `Upon reconnection with the replica, while initializing the dump thread for UUID uuid, an existing dump thread with the same UUID was detected. The source is terminating the previous dump thread (thread_id), which is normal and expected`로 개선되었습니다. (Bug #84358, Bug #25330090)
- **Group Replication:** 내부 함수 `cs::apply::Commit_order_queue::front()`와 `cs::apply::Commit_order_queue::remove()` 사이의 잠재적 race condition을 제거했습니다. (Bug #37223451)

  참조: 다음도 참조하십시오: Bug #35206392.

- **Group Replication:** 기본 노드가 예기치 않게 그룹을 떠난 뒤 빠르게 다시 조인하려고 시도했을 때, 다른 결함 있는 멤버를 제거하도록 선출된 멤버가 결함 있는 노드를 추방하거나 제거하려고 시도했지만 과반수 부족으로 인해 그렇게 할 수 없었습니다. 추방되거나 제거된 노드가 기본 노드였을 때, 이로 인해 클러스터에 기본 노드가 없는 상태가 되었고, 사용할 수 없는 상태가 발생했습니다. (Bug #36991859)

  References: 참고 항목: Bug #37181867.
- **Group Replication:** 일부 경우에는 새 보조 노드를 추가하면 기존 보조 노드가 지연되어, 기본 노드가 재시작될 때까지 더 이상 쓰기가 불가능한 상태로 지속되는 교착 상태가 발생했습니다.

  이 교착 상태는 트랜잭션이 뷰 변경의 올바른 쪽(뷰 변경 전 또는 후)에서 커밋되도록 보장하는 티켓 관리자와, 트랜잭션이 수신된 순서와 동일한 순서로 커밋되도록 보장하는 인바운드 복제 채널의 커밋 순서 관리자 사이에서, 이 두 관리자가 서로 다른 순서를 요구할 때 발생했습니다. 이는 일부 경우에 새 보조 노드를 추가하면 그룹 기본 노드가 쓰기를 수행할 수 없게 되었음을 의미합니다.

  이러한 교착 상태가 발생할 때 충돌하지 않는 트랜잭션에 대해 커밋 순서 관리자 순서를 무시하고 티켓 관리자 순서를 강제하여 이 문제를 해결합니다. 이로 인한 결과는 `View_change_log_event` 근처에서 [`replica_preserve_commit_order`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_replica_preserve_commit_order)가 엄격하게 준수되지 않을 수 있다는 것입니다. 다시 말해, `replica_preserve_commit_order`는 더 이상 Group Replication 기본 노드의 인바운드 채널에서 엄격한 보장을 제공하지 않습니다. [`replica_preserve_commit_order`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_replica_preserve_commit_order)는 여전히 트랜잭션이 올바르게 순서 지정되도록 보장하며, 유일한 예외는 뷰 변경 로그 이벤트 주변의 충돌하지 않는 트랜잭션입니다. (Bug #35206392)

  참조: 다음도 참조하십시오: Bug #37223451.
- **Group Replication:** `is_subset_not_equals()`에 대한 필수적이지 않은 호출을 제거하여 Group Replication의 가비지 컬렉션을 개선했습니다. (Bug #110673, Bug #35286974)
- **Group Replication:** 모든 멤버가 동일한 MySQL 버전을 실행 중인 그룹에서 그룹 멤버를 제거하고, 이를 이후 버전(이후 릴리스 시리즈의 버전)으로 업그레이드한 다음, 그룹에 다시 조인하도록 요청하면 업그레이드된 그룹 멤버가 recovering 상태에서 멈췄습니다.
- 오류 `ER_DD_UPDATE_DATADIR_FLAG_FAIL`, `ER_IB_MSG_FIL_STATE_MOVED_PREV_OR_HAS_DATADIR`, `ER_RPL_KILL_OLD_DUMP_THREAD_ENCOUNTERED`, 및 `ER_RPL_MTA_ALLOW_COMMIT_OUT_OF_ORDER`는 원래 MySQL 8.0에서 정의되었지만, 이후 MySQL 8.4에서 다른 오류 코드 번호(하지만 동일한 이름)가 할당되었습니다. MySQL 8.0에서 할당된 번호는 이제 MySQL 8.0에만 적용됩니다. MySQL 8.4 및 이후 릴리스 시리즈에서는 MySQL 8.4에서 할당된 번호만 사용됩니다. (Bug #37284176)
- `sql/item_cmpfunc.cc`에서 `Item_bool_func2::resolve_type()`은 `Item_bool_func::resolve_type()`에 대해 확인되지 않은 호출을 수행했습니다. `Item_bool_func::resolve_type()` 호출은 반환 값을 무시했으며, 오류가 발생한 경우에도 실행이 계속되었습니다. (Bug #37143289)
- AppArmor가 스택 추적을 생성하는 데 필요한 파일인 `/proc/$pid/task/$thread_id/mem`에 대한 접근을 거부했습니다. (Bug #37063288)

  참조: 다음도 참조하십시오: Bug #37387034.

- 하위 쿼리 실행에 [`index_subquery`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain-output.html#jointype_index_subquery) 조인 타입을 사용하는 쿼리에서, 하위 쿼리 테이블이 실행 계획에서 구체화를 사용한 경우 하위 쿼리의 필터 조건이 때때로 무시되었습니다. 파생 테이블 액세스 경로가 필터 조건을 대체하여, 필터 레이어가 없는 최종 계획이 생성되었습니다. 이를 수정하기 위해, 이러한 경우 이제 후자를 대체하는 대신 필터 액세스 경로와 함께 파생 테이블 액세스 경로를 추가합니다. (Bug #36918913)
- `a UNION b UNION c...`와 유사한 일부 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html) 작업이 과도한 메모리를 소비했습니다. 이러한 일이 발생하지 않도록 돕기 위해, 이제 컨텍스트화가 발생하기 전에 파싱 수준에서 동일한 집합 작업을 평탄화하며, 이로 인해 이러한 작업의 리소스 사용량이 줄어들어야 합니다. (Bug #36652610)
- 내부 함수 `my_print_help()`를 개선했습니다. (Bug #36615714)

  참조: 다음도 참조하십시오: Bug #37387224.
- `Acl_cache`에서 잘못된 코드를 제거했습니다. (Bug #36608160)
- 로우 값 비교자의 일부였던 집계 함수 `WITH ROLLUP`을 포함하는 하위 쿼리가 항상 올바르게 처리되지는 않았습니다. (Bug #36593235)

  참조: 다음도 참조하십시오: Bug #37387180. 이 문제는 다음의 회귀입니다: Bug #30969045, Bug #30921780, Bug #26227613, Bug #29134467, Bug #30967158.

- 변수를 영속화할 때 발생한 오류가 올바르게 보고되지 않을 수 있었습니다. (Bug #36574732)
- `WITH ROLLUP`을 사용하는 일부 서브쿼리가 항상 올바르게 처리되지 않았습니다. (Bug #36421704)
- MySQL이 예기치 않게 종료될 때 스택 트레이스를 출력하는 `my_print_stacktrace()`의 출력을 개선했습니다. (Bug #34904177, Bug #36027494)
- FTS 및 동시 DDL 또는 DML과 관련된 문제를 수정했습니다. (Bug #34633727)
- 같은 *`name`*의 테이블이 존재하는 경우 [`DROP VIEW name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/drop-view.html)이 [`ER_BAD_TABLE_ERROR`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_bad_table_error)와 함께 거부되었습니다. (Bug #33200087)
- 해시 테이블이 조인 버퍼에 맞지 않아 디스크로 스필될 때 해시 안티조인을 사용하는 일부 쿼리가 잘못된 결과를 반환했습니다. (문제를 유발한 쿼리는 실제로 `LEFT JOIN`을 지정했지만, 이는 내부적으로 왼쪽 외부 조인에서 안티조인으로 변환되었습니다.)

  문제는 프로브 로우를 청크 파일에 쓸 때 프로브 테이블의 일부 로우가 건너뛰어졌으며, 건너뛰어진 로우는 조인 키의 일부에 `NULL`이 있는 로우였다는 점입니다. 이러한 로우는 빌드 테이블에 일치 항목이 없는 것으로 알려져 있으므로 내부 조인과 세미조인에서는 건너뛸 수 있지만, 외부 조인과 안티조인에서는 빌드 테이블에 일치하는 로우가 없는 프로브 테이블의 로우가 조인 결과의 일부여야 하므로 청크 파일에 포함되어야 합니다.

  이미 외부 조인에 대해 이러한 로우를 청크 파일에 보존하고 있었습니다. 이 수정은 해당 목적에 사용되는 로직을 확장하여 안티조인에도 적용되도록 합니다. (Bug #116334, Bug #37161583)
- MySQL 8.0 이상에서 [`SELECT DISTINCT... FROM t1 WHERE NOT IN(SELECT...)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 형식의 쿼리는 가능한 경우 안티조인으로 변환되었으며, 이로 인해 MySQL 5.7에서는 선택되었을 테이블 t1에 대한 그룹 스킵 스캔을 Optimizer가 선택하지 않았습니다. 이로 인해 이러한 쿼리에서 성능 저하가 발생했습니다. 쿼리가 이제 안티조인 변환 이후 더 이상 단일 테이블 쿼리가 아니며, 이 접근 방식은 단일 테이블 쿼리에 대해서만 활성화되므로 그룹 스킵 스캔이 선택되지 않습니다. 세미조인으로 변환되는 쿼리에서도 동일한 동작을 볼 수 있습니다. 이러한 경우 접근 방식이 중복 제거에만 사용되는 경우(즉, `DISTINCT` 또는 `GROUP BY`와 함께 사용되지만 집계 함수는 없는 경우) 그룹 스킵 스캔 접근 방식을 계속 사용할 수 있습니다.

  이를 수정하기 위해, 원래 쿼리에 테이블이 하나만 있는 경우 내부 변환 이후 존재하는 세미조인 테이블 수와 관계없이, 쿼리에 집계 함수가 없는 한 그룹 스킵 스캔을 활성화합니다. (Bug #112362, Bug #35842412)
- **mysql** 클라이언트는 Optimizer 힌트 주석 안에서 '#' 또는 '--'를 사용하는 것을 허용하지 않았습니다.

  기여해 주신 Kaiwang Chen에게 감사드립니다. (Bug #98521, Bug #30875669)