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

## DBA를 위한 핵심 내용

MySQL 8.0.23은 복제 용어 변경, InnoDB/TempTable 운영성 개선, 권한 세분화가 DBA 영향의 중심입니다. 업그레이드 자체보다 운영 스크립트·모니터링·복제 관리 절차가 새 이름과 새 기본 동작을 제대로 반영하는지 확인하는 것이 중요하며, 웹 검색 기준 대규모 외부 회귀 이슈는 확인되지 않았습니다.

1. `CHANGE MASTER TO`가 사용 중단되고 `CHANGE REPLICATION SOURCE TO` 별칭이 도입되었습니다. 기존 명령은 계속 동작하지만 경고와 로그 재작성 영향이 있으므로 자동화, 감사 쿼리, 모니터링의 복제 용어를 점진적으로 교체해야 합니다.
2. `master_info_repository`, `relay_log_info_repository`, `FLUSH HOSTS`가 사용 중단 흐름에 들어갔습니다. 복제 메타데이터는 InnoDB 테이블 기반을 전제로 점검하고, 호스트 캐시 플러시는 `TRUNCATE performance_schema.host_cache` 권한 모델로 전환하는 것이 안전합니다.
3. InnoDB는 tablespace 삭제·임시 tablespace truncate·undo truncate·page cleaner 관련 병목이 다수 개선되었습니다. 대형 버퍼 풀, 높은 update 빈도, undo 자동 truncate 사용 환경은 업그레이드 후 purge 지연과 flush 지표를 비교 점검하십시오.
4. `AUTOEXTEND_SIZE`, 암호화 tablespace의 doublewrite 페이지 암호화, `temptable_max_mmap`이 추가되었습니다. 대량 적재·임시 테이블·암호화 운영 환경에서는 파일 증가 단위, mmap 사용량, 디스크 임시 테이블 전환 시점을 재산정해야 합니다.
5. Group Replication/비동기 복제 페일오버가 관리형 그룹 소스와 트랜잭션 크기 제한을 더 명확히 처리합니다. 특히 `group_replication_transaction_size_limit` 초과 트랜잭션은 실패할 수 있으므로 대형 트랜잭션 배치 작업을 사전 점검해야 합니다.
6. 8.0.22에서 도입된 prepared statement 변경과 관련한 JSON/콜레이션/저장 프로그램 회귀가 다수 수정되었습니다. 8.0.22를 건너뛰거나 사용 중인 경우, prepared statement·JSON 함수·저장 프로시저 중심 회귀 테스트를 포함해 업그레이드 검증을 수행하십시오.

## 계정 관리 관련 사항

- [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한을 부여하면 사용자가 매우 다양한 작업을 수행할 수 있습니다. 경우에 따라 사용자가 이러한 작업 중 일부만 수행할 수 있게 하는 것이 바람직할 수 있습니다. DBA가 [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 부여를 피하고 허용된 작업에 더 가깝게 사용자 권한을 조정할 수 있도록, 범위가 더 제한된 다음 새 권한을 사용할 수 있습니다:

  - [`FLUSH_OPTIMIZER_COSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_flush-optimizer-costs): [`FLUSH OPTIMIZER_COSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-optimizer-costs) 문을 사용할 수 있게 합니다.
  - [`FLUSH_STATUS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_flush-status): [`FLUSH STATUS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-status) 문을 사용할 수 있게 합니다.
  - [`FLUSH_TABLES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_flush-tables): [`FLUSH TABLES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-tables) 문을 사용할 수 있게 합니다.
  - [`FLUSH_USER_RESOURCES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_flush-user-resources): [`FLUSH USER_RESOURCES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-user-resources) 문을 사용할 수 있게 합니다.

  새 권한은 전역 수준에서만 적용됩니다. 자세한 내용은 [Privileges Provided by MySQL](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html) 및 [FLUSH Statement](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html)를 참조하십시오.

  [`mysql_refresh()`](https://docs.oracle.com/cd/E17952_01/c-api-8.0-en/mysql-refresh.html) C API 함수는 여러 [`FLUSH`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html) 문과 유사한 작업을 수행하지만, 이 변경의 영향을 받지 않습니다. 이 함수는 호출되는 작업과 관계없이 여전히 [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한을 필요로 합니다. (WL #14303)

## C API 관련 사항

- 일부 애플리케이션에서는 쿼리별로 메타데이터를 정의하는 것이 유용할 수 있습니다. 예로는 쿼리를 생성한 페이지의 URL이나, 감사 플러그인 또는 쿼리 재작성 플러그인 같은 플러그인에서 사용하도록 쿼리와 함께 전달할 추가 처리 정보가 있습니다. MySQL은 이제 쿼리 문자열에 포함되는 특수 형식의 주석 같은 우회 방법을 사용하지 않고도 이 기능을 지원합니다:

  - 클라이언트 측에서는 [`mysql_bind_param()`](https://docs.oracle.com/cd/E17952_01/c-api-8.0-en/mysql-bind-param.html) C API 함수가 쿼리 속성 정의를 가능하게 합니다. 이러한 속성은 실행을 위해 서버로 전송되는 다음 SQL 문에 적용됩니다. 또한 **mysql** 및 **mysqltest** 클라이언트에는 쿼리 속성 정의를 가능하게 하는 `query_attributes` 명령이 있습니다.
  - 서버 측에서는 컴포넌트 서비스가 쿼리 속성에 대한 접근을 제공합니다. `query_attributes`라는 이름의 컴포넌트는 이 서비스를 사용하여 SQL 문 내에서 속성 값을 가져올 수 있게 하는 [`mysql_query_attribute_string()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/query-attributes.html#function_mysql-query-attribute-string) 로드 가능 함수를 구현합니다. `query_attributes` 컴포넌트는 선택 사항이지만, 이 함수를 사용할 수 있으려면 설치되어야 합니다.

  자세한 내용은 [쿼리 속성](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/query-attributes.html)을 참조하십시오.

  아이디어를 제안해 준 Facebook에 감사드립니다(코드도 기여했지만, 사용되지는 않았습니다). (Bug #27855905, Bug #28686334, WL #12542)

## 컴파일 관련 사항

- aarch64 (ARM64)에서 MySQL을 컴파일하기 위한 패치를 제공한 Tzachi Zidenberg에게 감사드립니다. (Bug #31815236, Bug #100664)

## 연결 관리 관련 사항

- 수신 TCP 클라이언트 연결과 일치하는 계정 선택은 계정 생성 순서의 영향을 받을 수 있었습니다. 일치 알고리즘을 더 결정적으로 만들기 위해, 이제 계정의 호스트 이름 부분을 일치시킬 때 호스트 이름을 사용하여 지정된 계정과 일치를 시도하기 전에, 호스트 IP 주소를 사용하여 지정된 계정을 특정 순서로 확인합니다. 호스트 이름 일치는 변경되지 않았습니다. [Access Control, Stage 1: Connection Verification](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-access.html)을 참조하십시오. (WL #14074)

## 사용 중단 및 제거 관련 사항

- MySQL 8.0.23부터 명령문 [`CHANGE MASTER TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-master-to.html)는 사용 중단되었습니다. 대신 별칭 [`CHANGE REPLICATION SOURCE TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html)를 사용해야 합니다. 이 명령문의 매개변수에도 `MASTER` 용어를 `SOURCE` 용어로 대체하는 별칭이 있습니다. 예를 들어, 이제 `MASTER_HOST` 및 `MASTER_PORT`를 `SOURCE_HOST` 및 `SOURCE_PORT`로 입력할 수 있습니다. [`START REPLICA | SLAVE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/start-replica.html) 명령문의 매개변수 `MASTER_LOG_POS` 및 `MASTER_LOG_FILE`에는 이제 별칭 `SOURCE_LOG_POS` 및 SOURCE_LOG_FILE이 있습니다. 이 명령문은 이전과 동일한 방식으로 동작하며, 각 명령문에 사용되는 용어만 변경되었습니다. 이전 버전을 사용하는 경우 사용 중단 경고가 발생합니다.

  새 상태 변수 `Com_change_replication_source`가 `Com_change_master` 상태 변수의 별칭으로 추가되었습니다. 이전 버전 및 새 버전의 명령문은 이전 버전 및 새 버전의 상태 변수를 모두 업데이트합니다.

  서버는 쿼리 로그에서 모든 [`CHANGE MASTER TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-master-to.html) 명령문을 [`CHANGE REPLICATION SOURCE TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html) 명령문으로 다시 작성합니다. 명령문 `START SLAVE`, `STOP SLAVE`, `SHOW SLAVE STATUS`, `SHOW SLAVE HOSTS` 및 `RESET SLAVE`에도 동일하게 적용됩니다. [`CHANGE MASTER TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-master-to.html) 명령문의 이벤트 이름은 명령문 기록 테이블에서 `statement/sql/change_replication_source`로 설정됩니다. (Bug #32145023, WL #14189)
- [`gen_blacklist()`](https://docs.oracle.com/cd/E17952_01/mysql-5.7-en/data-masking-functions.html#function_gen-blacklist) 사용자 정의 함수는 사용 중단되었습니다. 동일한 용어 대체 작업을 수행하는 [`gen_blocklist()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/data-masking-component-functions.html#function_gen-blocklist)를 대신 사용하십시오. (WL #14176)

- 시스템 변수 `master_info_repository` 및 `relay_log_info_repository`의 사용은 이제 더 이상 권장되지 않으며, 이를 설정하거나 해당 값을 읽으려고 하면 경고 메시지가 발생합니다. 이 시스템 변수는 향후 MySQL 버전에서 제거됩니다. 이 시스템 변수는 복제본의 연결 메타데이터 저장소와 applier 메타데이터 저장소를 mysql 시스템 데이터베이스의 `InnoDB` 테이블에 기록할지, 데이터 디렉터리의 파일에 기록할지를 지정하는 데 사용되었습니다. `FILE` 설정은 이전 릴리스에서 이미 더 이상 권장되지 않았으며, MySQL 8.0에서는 복제 메타데이터 저장소의 기본값이 테이블입니다. (WL #13958)
- 호스트 캐시 플러시는 다음 방법 중 하나를 사용하여 수행할 수 있습니다:

  - Performance Schema [`host_cache`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-host-cache-table.html) 테이블을 잘라내는 [`TRUNCATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/truncate-table.html) 문을 실행합니다. 이를 위해서는 해당 테이블에 대한 [`DROP`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_drop) 권한이 필요합니다.
  - [`FLUSH HOSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-hosts) 문을 실행합니다. 이를 위해서는 [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한이 필요합니다.
  - **mysqladmin flush-hosts** 명령을 실행합니다. 이를 위해서는 [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한이 필요합니다.

  이러한 방법은 효과 면에서 동일하지만, [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한을 부여하면 호스트 캐시 플러시 외에도 여러 다른 작업이 가능해지므로 보안 관점에서 바람직하지 않습니다. [`host_cache`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-host-cache-table.html) 테이블에 대해 [`DROP`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_drop) 권한을 부여하는 것이 범위가 더 제한적이므로 더 적합합니다. 따라서 [`FLUSH HOSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-hosts) 문은 더 이상 권장되지 않으며 향후 MySQL 버전에서 제거됩니다. 대신 [`host_cache`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-host-cache-table.html) 테이블을 잘라내십시오.

    **mysqladmin flush-hosts**는 이전에 [`FLUSH HOSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-hosts) 문을 실행했습니다. 이제는 `host_cache` 테이블을 잘라내려고 시도하며, truncate 작업이 실패하는 경우에만 [`FLUSH HOSTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-hosts)로 폴백합니다. (WL #14329)

## Firewall 관련 사항

- 관리자는 허용된 구문에 대한 규칙 집합(허용 목록)을 지정하는 프로파일을 등록하여 MySQL Enterprise Firewall 관리를 수행합니다. 이전에는 프로파일을 개별 계정에만 연결할 수 있었으므로, 지정된 허용 목록을 여러 계정 프로파일에 적용하려면 각 프로파일에 대해 규칙 집합을 중복해야 했습니다. 더 쉬운 관리와 더 큰 유연성을 위해, 이제 Firewall은 그룹 프로파일 기능을 제공합니다:

  - 이름이 지정된 그룹 프로파일을 생성할 수 있습니다. 그룹 프로파일은 여러 계정을 멤버로 포함할 수 있으며, 계정은 여러 그룹 프로파일의 멤버가 될 수 있습니다.
  - 각 그룹 프로파일에는 자체 허용 목록이 있습니다. 프로파일 허용 목록은 모든 멤버 계정에 적용되므로, 여러 계정 프로파일에 걸쳐 이를 중복할 필요가 없어집니다.

  자세한 내용은 [MySQL Enterprise Firewall](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/firewall.html)을 참조하십시오. (WL #11740)

## Optimizer 관련 사항

- 해시 조인에 사용되는 해시 테이블을 unordered multimap에서 multimap 어댑터로 구현된 unordered flat map으로 전환했습니다. 이 변경으로 다음과 같은 개선 사항이 제공됩니다:

  - 더 빠른 해시 테이블
  - 해시 테이블 오버헤드 감소, 정렬 및 키/값 길이에 사용되는 공간 감소, 동일한 키가 많은 경우의 메모리 사용 개선으로 인한 메모리 사용량 감소; 이로 인해 디스크로 spill해야 하는 빈도도 줄어들어야 합니다
  - 허용된 조인 버퍼 크기에 더 가깝게 접근하여 사실상 [`join_buffer_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_join_buffer_size)의 약 2/3로 제한되는 대신 더 나은 메모리 제어를 제공하고, 해시 테이블이 커질 때 이전 메모리를 해제할 수 있게 합니다

  (Bug #99933, Bug #31516149, WL #13459)

## Performance Schema 관련 사항

- 이전에 동적 호출로 확장되던 Performance Schema 매크로는 처리 오버헤드를 줄이기 위해 가능한 경우 이제 정적 호출로 확장됩니다. (Bug #32028160)
- 타이머 코드의 성능 오버헤드가 줄었습니다. 이는 Performance Schema를 사용하는 높은 동시성 워크로드에 가장 큰 이점을 제공할 것입니다. 기여해 주신 Georgy Kirichenko에게 감사드립니다. (Bug #31960377, Bug #101018)

## Pluggable Authentication 관련 사항

- MySQL Enterprise Edition SASL LDAP 인증 플러그인은 이제 MySQL 클라이언트와 서버의 인증 방법으로 `SCRAM-SHA-256`을 지원합니다. `SCRAM-SHA-256`은 `SCRAM-SHA-1`과 유사하지만 더 안전합니다. `SCRAM-SHA-256`을 사용하려면 Cyrus SASL 2.1.27 이상을 사용하여 빌드된 OpenLDAP 서버가 필요합니다. [LDAP Authentication Methods](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/ldap-pluggable-authentication.html#ldap-pluggable-authentication-auth-methods)를 참조하십시오. (WL #14180)

## 보안 관련 사항

- OpenSSL 라이브러리가 번들로 제공되는 플랫폼의 경우, MySQL Server에 링크된 OpenSSL 라이브러리가 버전 1.1.1i로 업데이트되었습니다. 새 OpenSSL 버전에서 수정된 문제는 [https://www.openssl.org/news/cl111.txt](https://www.openssl.org/news/cl111.txt) 및 [https://www.openssl.org/news/vulnerabilities.html](https://www.openssl.org/news/vulnerabilities.html)에 설명되어 있습니다. (Bug #32260610)

## 공간 데이터 지원

- 새로운 [`ST_HausdorffDistance()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/spatial-relation-functions-object-shapes.html#function_st-hausdorffdistance) 및 [`ST_FrechetDistance()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/spatial-relation-functions-object-shapes.html#function_st-frechetdistance) 함수는 두 지오메트리 사이의 이산 Fréchet 거리와 Hausdorff 거리를 반환하며, 지오메트리가 얼마나 유사한지를 반영합니다. [객체 형상을 사용하는 공간 관계 함수](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/spatial-relation-functions-object-shapes.html)를 참조하십시오. (WL #14128, WL #14129)

## SQL 문법 관련 사항

- MySQL은 이제 invisible column을 지원하며, 이는 일반적으로 쿼리에서 숨겨지지만 명시적으로 참조하는 경우 접근할 수 있습니다. [Invisible Columns](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/invisible-columns.html)를 참조하십시오. (WL #10905)

## X 플러그인 관련 사항

- `MYSQL41` 인증 방식을 사용하는 X Protocol 연결의 경우, 서버가 보낸 nonce가 20바이트보다 짧으면 연결 로직이 이를 올바르게 처리하지 못했습니다. (Bug #32036194)
- 결과 집합을 구성 중이던 쿼리가 종료되면 X Plugin은 이를 서버 세션이 종료되었다는 의미로 해석하고 연결을 끊었습니다. 이제 쿼리의 상태는 서버 세션의 상태와 별도로 확인됩니다. (Bug #31954296)
- 한 X Protocol 세션이 X Plugin 상태 변수 또는 설정을 표시하려고 시도하는 동시에 다른 X Protocol 세션이 해제 및 재설정되는 경우 교착 상태가 발생할 수 있었습니다. 이제 이 상황이 적절하게 처리됩니다. (Bug #31931873)
- 서버에 연결된 X Protocol 클라이언트가 관련 X Plugin 타임아웃 설정(read, write 또는 wait timeout)보다 오래 유휴 상태(서버로 전송하지 않음)로 유지되면 X Plugin은 연결을 닫습니다. read timeout의 경우 플러그인은 클라이언트 애플리케이션에 오류 코드 ER_IO_READ_ERROR와 함께 경고 알림을 반환합니다.

  MySQL 8.0.23부터 X Plugin은 서버 종료로 인해 또는 다른 클라이언트 세션에서 연결이 종료되어 연결이 능동적으로 닫히는 경우에도 경고 알림을 보냅니다. 서버 종료의 경우 경고 알림은 열려 있는 연결을 가진 인증된 모든 X Protocol 클라이언트에 ER_SERVER_SHUTDOWN 오류 코드와 함께 전송됩니다. 종료된 연결의 경우 해당 연결이 SQL 실행 중에 종료된 경우를 제외하고 경고 알림은 관련 클라이언트에 ER_SESSION_WAS_KILLED 오류 코드와 함께 전송되며, SQL 실행 중에 종료된 경우에는 ER_QUERY_INTERRUPTED 오류 코드와 함께 치명적 오류가 반환됩니다.

  클라이언트 애플리케이션은 사용자에게 표시하거나 연결 해제 이유를 분석하고 동일한 서버 또는 다른 서버로 재연결을 시도할지 결정하는 데 경고 알림을 사용할 수 있습니다. (WL #14166)
- 클래식 MySQL 프로토콜의 경우 SQL 쿼리가 메타데이터 잠금 또는 sleep 함수를 사용 중이면 서버와의 연결이 아직 살아 있는지 확인하기 위해 주기적으로 점검됩니다. 그렇지 않으면 쿼리가 리소스를 계속 소비하지 않도록 중지될 수 있습니다. 이전에는 X Protocol이 이러한 검사를 수행하지 않고 연결이 아직 살아 있다고 가정했습니다. 이제 X Protocol에 이 검사가 추가되었습니다. (WL #14167)

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

- **InnoDB:** 다음 작업의 성능이 향상되었습니다:

  - 큰 버퍼 풀(>32GBs)이 있는 MySQL 인스턴스에서 큰 테이블스페이스 삭제.
  - adaptive hash index에서 참조되는 페이지 수가 상당한 테이블스페이스 삭제.
  - 임시 테이블스페이스 잘라내기.

  삭제되거나 잘라낸 테이블스페이스의 페이지와 연결된 AHI 엔트리는 이제 일반 작업 중 페이지가 발견될 때 버퍼 풀에서 수동적으로 제거됩니다. 이전에는 테이블스페이스를 삭제하거나 잘라내면 버퍼 풀에서 페이지를 즉시 제거하기 위해 전체 목록 스캔이 시작되었으며, 이는 성능에 부정적인 영향을 주었습니다. (Bug #31008942, Bug #98869, WL #14100)
- **InnoDB:** 새로운 `AUTOEXTEND_SIZE` 옵션은 `InnoDB`가 테이블스페이스가 가득 찼을 때 테이블스페이스 크기를 확장하는 양을 정의하여, 테이블스페이스 크기를 더 큰 증분으로 확장할 수 있게 합니다. 더 큰 증분으로 공간을 할당하면 단편화를 방지하는 데 도움이 되며 대량의 데이터 수집을 용이하게 합니다. `AUTOEXTEND_SIZE` 옵션은 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html), [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html), [`CREATE TABLESPACE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-tablespace.html), 및 [`ALTER TABLESPACE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-tablespace.html) 문에서 지원됩니다. 자세한 내용은 [Tablespace AUTOEXTEND_SIZE Configuration](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-tablespace-autoextend-size.html)을 참조하십시오.

  `AUTOEXTEND_SIZE` 크기 컬럼이 [`INFORMATION_SCHEMA.INNODB_TABLESPACES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-innodb-tablespaces-table.html) 테이블에 추가되었습니다. (WL #13895)
- **InnoDB:** `InnoDB`는 이제 암호화된 테이블스페이스에 속하는 doublewrite 파일 페이지의 암호화를 지원합니다. 페이지는 연결된 테이블스페이스의 암호화 키를 사용하여 암호화됩니다. 자세한 내용은 [InnoDB Data-at-Rest Encryption](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-data-encryption.html)을 참조하십시오. (WL #13775)
- **InnoDB:** `InnoDB` atomics 코드는 C++ `std::atomic`을 사용하도록 개정되었습니다. (WL #14235)

- **Group Replication:** MySQL Server 비동기 연결 장애 조치 메커니즘은 이제 그룹 멤버십 변경을 자동으로 모니터링하고 프라이머리 서버와 세컨더리 서버를 구분하여 Group Replication 토폴로지를 지원합니다. 소스 목록에 그룹 멤버를 추가하고 이를 관리되는 그룹의 일부로 정의하면, 비동기 연결 장애 조치 메커니즘은 소스 목록을 업데이트하여 멤버십 변경과 일치하도록 유지하고, 그룹 멤버가 참여하거나 떠날 때 자동으로 추가 및 제거합니다. 새로운 `asynchronous_connection_failover_add_managed()` 및 `asynchronous_connection_failover_delete_managed()` 함수는 관리되는 소스를 추가하고 제거하는 데 사용됩니다.

  연결은 다음 상황에서 다른 그룹 멤버로 장애 조치됩니다:

  - 현재 연결된 소스가 오프라인이 되거나 그룹을 떠납니다.
  - 현재 연결된 소스가 더 이상 과반수에 속하지 않습니다.
  - 현재 연결된 소스가 그룹에서 가장 높은 가중치 우선순위를 갖지 않습니다.

  관리되는 그룹의 경우 소스의 가중치는 프라이머리 서버인지 세컨더리 서버인지에 따라 할당됩니다. 따라서 관리되는 그룹이 프라이머리에 더 높은 가중치를, 세컨더리에 더 낮은 가중치를 부여하도록 설정했다고 가정하면, 프라이머리가 변경될 때 더 높은 가중치가 새 프라이머리에 할당되므로 레플리카는 해당 프라이머리로 연결을 전환합니다. 이는 단일(관리되지 않는) 서버에도 적용되므로, 더 높은 가중치 우선순위를 가진 다른 소스 서버가 사용 가능하면 이제 단일 서버의 연결도 장애 조치됩니다. (WL #14019)
- [`--all-databases`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqldump.html#option_mysqldump_all-databases) 옵션과 함께 호출될 때, 이제 **mysqldump**는 먼저 **mysql** 데이터베이스를 덤프하므로, 덤프 파일이 다시 로드될 때 다른 객체의 `DEFINER` 절에 이름이 지정된 모든 계정이 이미 생성되어 있습니다. (Bug #32141046)
- 비활성화된 Performance Schema 및 `LOCK_ORDER` 도구 인스트루멘테이션의 일부 오버헤드가 식별되어 제거되었습니다. (Bug #32105698)
- 기본값 표현식이 있는 `BLOB` 및 `TEXT` 컬럼의 경우, 이제 [`INFORMATION_SCHEMA.COLUMNS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-columns-table.html) 테이블과 [`SHOW COLUMNS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-columns.html) 문은 해당 표현식을 표시합니다. (Bug #31856459)

- 다중 스레드 복제본([`slave_parallel_workers`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_slave_parallel_workers)가 0보다 큰 경우)의 경우, [`slave_preserve_commit_order=1`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_slave_preserve_commit_order)을 설정하면 트랜잭션이 복제본의 릴레이 로그에 나타나는 것과 같은 순서로 복제본에서 실행되고 커밋되도록 보장합니다. 실행 중인 각 워커 스레드는 커밋하기 전에 이전의 모든 트랜잭션이 커밋될 때까지 대기합니다. 가능한 데드락이 감지되었거나 트랜잭션의 실행 시간이 관련 대기 타임아웃을 초과했기 때문에 워커 스레드가 트랜잭션 실행에 실패하면, 오류와 함께 중지되기 전에 [`slave_transaction_retries`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_slave_transaction_retries)에 지정된 횟수만큼 자동으로 재시도합니다. 임시적이지 않은 오류가 있는 트랜잭션은 재시도되지 않습니다.

  다중 스레드 복제본의 복제 적용기는 관련 스토리지 엔진에서 식별한 데이터 접근 데드락을 항상 처리해 왔습니다. 그러나 접근 제어 목록(ACL) 또는 메타데이터 잠금(예: `FLUSH TABLES WITH READ LOCK` 문)과 관련된 잠금 같은 일부 다른 유형의 잠금은 복제 적용기에서 감지되지 않았습니다. 이로 인해 커밋 순서 잠금과 함께 세 행위자 데드락이 발생할 수 있었으며, 이는 복제 적용기가 해결할 수 없었고 복제가 무기한 중단되도록 했습니다. MySQL 8.0.23부터 커밋 순서를 보존하는 다중 스레드 복제본의 데드락 처리가 향상되어 이러한 유형의 데드락을 완화합니다. 데드락은 복제 적용기에서 구체적으로 해결되지는 않지만, 적용기는 이를 인식하고 중단되는 대신 트랜잭션에 대한 자동 재시도를 시작합니다. 재시도가 모두 소진되면, 데드락을 수동으로 해결할 수 있도록 복제가 제어된 방식으로 중지됩니다. (Bug #107574, Bug #34291887, WL #13574)
- ARM 플랫폼에서 binlog 체크섬을 위한 CRC 계산이 더 빨라졌습니다. 기여해 주신 Krunal Bauskar에게 감사드립니다. (Bug #99118, Bug #31101633, Bug #32163391)

- 이제 `CHANGE REPLICATION SOURCE TO` 문의 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` 옵션을 사용하여, 아직 GTID가 없는 복제된 트랜잭션에 GTID를 할당하도록 복제 채널을 설정할 수 있습니다. 이 기능은 GTID 기반 복제를 사용하지 않는 소스에서 GTID 기반 복제를 사용하는 레플리카로 복제할 수 있게 합니다. 다중 소스 레플리카의 경우 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`를 사용하는 채널과 사용하지 않는 채널을 혼합할 수 있습니다. GTID에는 레플리카 자체의 서버 UUID 또는 서로 다른 소스의 트랜잭션을 식별하기 위해 사용자가 할당하는 서버 UUID가 포함될 수 있습니다.

  어떤 채널에서든 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`를 사용하도록 설정된 레플리카는 장애 조치가 필요한 경우 복제 소스 서버를 대체하도록 승격할 수 없으며, 해당 레플리카에서 가져온 백업은 복제 소스 서버를 복원하는 데 사용할 수 없습니다. 동일한 제한은 어떤 채널에서든 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`를 사용하는 다른 레플리카를 대체하거나 복원하는 경우에도 적용됩니다. `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`를 사용하도록 설정된 레플리카의 GTID 세트(gtid_executed)는 비표준이며 다른 서버로 전송하거나 다른 서버의 `gtid_executed` 세트와 비교해서는 안 됩니다. (WL #12819)
- 새 [`temptable_max_mmap`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_temptable_max_mmap) 변수는 TempTable 스토리지 엔진이 디스크의 `InnoDB` 내부 임시 테이블에 데이터를 저장하기 시작하기 전에, 메모리 매핑된 임시 파일에서 할당하도록 허용되는 최대 메모리 양을 정의합니다. 0으로 설정하면 메모리 매핑된 임시 파일에서 메모리 할당이 비활성화됩니다. 자세한 내용은 [Internal Temporary Table Use in MySQL](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/internal-temporary-tables.html)을 참조하십시오. (WL #14125)

## 수정된 버그

- **InnoDB:** 홀 펀칭을 지원하지 않는 시스템에서 `COMPRESSION` 옵션을 지정한 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html) 작업이 경고와 함께 허용되었습니다. 이제 이 작업은 대신 오류와 함께 실패합니다. (Bug #32174200)
- **InnoDB:** 데이터 로드 작업이 진행 중인 동안 시작된 업그레이드 이후 MySQL DB 시스템을 재시작하면 assertion failure가 발생했습니다. (Bug #32173596)
- **InnoDB:** 체크포인트 사이에 동일한 undo 테이블스페이스에 대한 truncate 작업 수와 관련된 오류 메시지가 제한을 64로 잘못 표시했습니다. 이 제한은 MySQL 8.0.22에서 64에서 50,000으로 증가되었습니다. (Bug #32151601, Bug #101601)
- **InnoDB:** `rw_lock_t` 및 `buf_block_t` 소스 코드 구조체의 크기가 줄었습니다. (Bug #32084500)
- **InnoDB:** `InnoDB` 테이블에서 동작하는 쿼리 표현식으로부터 `InnoDB`가 아닌 스토리지 엔진을 사용하여 테이블을 생성한 후 [`InnoDB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-storage-engine.html) 트랜잭션이 일관되지 않은 상태가 되었습니다. (Bug #32079103)

- **InnoDB:** 기존 갭 잠금이 삭제된 레코드에서 잠금을 상속하는 경우와 같은 일부 상황에서, [`INFORMATION_SCHEMA.INNODB_TRX`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-innodb-trx-table.html) 테이블에 표시되는 잠금 수가 실제 레코드 잠금 수와 달라질 수 있었습니다.

  패치를 제공해 주신 Alibaba의 Fungo Wang에게 감사드립니다. (Bug #32068538, Bug #101305)
- **InnoDB:** `Fil_system` 샤딩 코드의 off-by-one 오류가 수정되었으며, 최대 샤드 수(`MAX_SHARDS`)가 69로 변경되었습니다. (Bug #32052821, Bug #101260)
- **InnoDB:** TempTable 스토리지 엔진 메모리 할당자가 불필요하게 추가 메모리 블록을 할당했습니다. (Bug #32018553)
- **InnoDB:** 커밋되지 않은 데이터를 포함하는 테이블에서 `SELECT COUNT(*)` 작업이 불필요한 I/O로 인해 성능이 저하되었습니다.

  기여해 주신 Brian Yue에게 감사드립니다. (Bug #31997733, Bug #100966)
- **InnoDB:** 로그 writer를 종료할 때 발생한 경쟁 조건으로 인해 어설션 실패가 발생했습니다. (Bug #31997362)
- **InnoDB:** sync-flush 모드에서 page cleaner 스레드가 최적으로 활용되지 않아, 일부 경우 페이지 플러시 작업이 느려지거나 정지될 수 있었습니다. sync-flush 모드는 `InnoDB`가 redo 로그의 여유 공간을 거의 모두 소진하려고 할 때 발생하며, 이로 인해 page cleaner coordinator가 공격적인 페이지 플러시를 시작합니다. (Bug #31994031)

- **InnoDB:** undo log truncation이 활성화된 상태에서 높은 빈도의 업데이트가 발생하면 purge가 지연되었습니다. 이 지연은 undo 테이블스페이스가 truncation 대상으로 선택될 때 [`innodb_purge_rseg_truncate_frequency`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_purge_rseg_truncate_frequency) 설정이 일시적으로 128에서 1로 변경되었기 때문입니다. 해당 설정을 수정하던 코드는 제거되었습니다. (Bug #31991688)
- **InnoDB:** undo 테이블스페이스의 자동 truncation으로 인해 성능 저하가 발생했습니다. 이 문제를 해결하기 위해, undo 테이블스페이스 파일은 이제 16MB로 초기화되고 최소 16MB씩 확장됩니다. 급격한 증가를 처리하기 위해, 이전 파일 확장이 0.1초보다 짧은 시간 전에 발생한 경우 파일 확장 크기가 두 배로 증가합니다. 확장 크기의 배가는 최대 256MB까지 여러 번 발생할 수 있습니다. 이전 파일 확장이 0.1초보다 긴 시간 전에 발생한 경우, 확장 크기는 절반으로 줄어들며, 이 또한 여러 번 발생하여 최소 16MB까지 줄어들 수 있습니다. 이전에는 undo 테이블스페이스의 초기 크기가 `InnoDB` 페이지 크기에 따라 달라졌으며, undo 테이블스페이스는 한 번에 네 개의 extent씩 확장되었습니다.

  undo 테이블스페이스에 대해 `AUTOEXTEND_SIZE` 옵션이 정의된 경우, undo 테이블스페이스는 `AUTOEXTEND_SIZE` 설정과 위에서 설명한 로직으로 결정된 확장 크기 중 더 큰 값만큼 확장됩니다.

  undo 테이블스페이스가 truncated될 때, 일반적으로 16MB 크기로 다시 생성되지만, 현재 파일 확장 크기가 16MB보다 크고 이전 파일 확장이 마지막 1초 이내에 발생한 경우, 새 undo 테이블스페이스는 [`innodb_max_undo_log_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_max_undo_log_size) 변수로 정의된 크기의 1/4 크기로 생성됩니다.

  Stale undo 테이블스페이스 페이지는 더 이상 다음 체크포인트에서 제거되지 않습니다. 대신 해당 페이지는 백그라운드에서 `InnoDB` 마스터 스레드에 의해 제거됩니다. (Bug #31965404, Bug #32020900, Bug #101194)
- **InnoDB:** 임시 테이블스페이스를 위한 공간을 사전 할당하는 동안 `posix_fallocate()` 실패가 오류를 발생시키고 초기화 실패를 유발했습니다. 이제 대신 경고가 발생하며, `InnoDB`는 공간 사전 할당을 위해 non-`posix_fallocate()` 메서드로 폴백합니다. (Bug #31965379)
- **InnoDB:** 잘못된 포인터로 인해 [`DISABLE_PSI_MEMORY`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/source-configuration-options.html#option_cmake_disable_psi_memory) 소스 설정 옵션이 활성화된 상태로 컴파일된 MySQL Server에서 종료 실패가 발생했습니다. (Bug #31963333)
- **InnoDB:** 지정된 인덱스에 대한 새 통계를 계산하는 내부 함수가 보유한 긴 SX 락으로 인해 실패가 발생했습니다. (Bug #31889883)

- **InnoDB:** [`INFORMATION_SCHEMA.INNODB_TABLESPACES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-innodb-tablespaces-table.html) 테이블이 일부 테이블 및 스키마에 대해 `FILE_SIZE`를 0으로 보고했습니다. 관련 테이블스페이스가 메모리 캐시에 없을 때, 테이블스페이스 이름을 사용하여 테이블스페이스 파일 이름을 확인했으며, 이는 항상 신뢰할 수 있는 방법은 아니었습니다. 이제 대신 테이블스페이스 ID가 사용됩니다. 테이블스페이스 이름을 사용하는 방법은 fallback 방법으로 유지됩니다. (Bug #31841617)
- **InnoDB:** `FULLTEXT` 인덱스를 삭제하고 테이블 이름을 변경하여 새 스키마로 이동한 후, `FULLTEXT` 보조 테이블의 이름이 그에 맞게 변경되지 않고 이전 스키마 디렉터리에 남아 있었습니다. (Bug #31773368, Bug #100570)
- **InnoDB:** MySQL 8.0으로 업그레이드한 후, 이전에 full-text search 인덱스로 정의된 테이블에서 DML 작업을 수행하려고 할 때 실패가 발생했습니다. (Bug #31749490)

- **InnoDB:** 페이지 압축 테이블이 포함된 테이블스페이스를 임포트할 때, 서로 다른 `COMPRESSION` 설정으로 정의된 소스 테이블과 대상 테이블에 대해 스키마 불일치 오류가 보고되지 않았습니다. 이제 익스포트된 테이블의 `COMPRESSION` 설정은 [`FLUSH TABLES... FOR EXPORT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-tables-for-export-with-list) 작업 중 `.cfg` 메타데이터 파일에 저장되며, 임포트 시 두 테이블이 동일한 `COMPRESSION` 설정으로 정의되었는지 확인하기 위해 해당 정보가 검사됩니다. (Bug #31744694)
- **InnoDB:** MySQL Keyring 플러그인이 작동하는지 확인하는 데 사용되는 더미 키가 비활성 상태로 남아 있었으며, 비활성 더미 키의 수가 시간이 지남에 따라 증가했습니다. 이제 실제 마스터 키가 있으면 대신 해당 키가 사용됩니다. 사용할 수 있는 마스터 키가 없으면 더미 마스터 키가 생성됩니다. (Bug #31737924)
- **InnoDB:** `InnoDB` 시스템 테이블스페이스를 데이터 디렉터리 밖으로 이동한 후 [`INFORMATION_SCHEMA.FILES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-files-table.html) 테이블을 쿼리하면 `innodb_system` 파일명을 알 수 없음을 나타내는 경고가 발생했습니다. (Bug #31603047)

- **InnoDB:** 바이너리 로깅 또는 [`log_slave_updates`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_log_slave_updates)가 비활성화된 레플리카가 포함된 복제 시나리오에서, `mysql.gtid_executed` 테이블에 과도한 수의 gap이 있어 서버가 시작되지 못했습니다. 이 gap은 `InnoDB` 및 non-`InnoDB` 트랜잭션을 모두 포함하는 워크로드에서 발생했습니다. `InnoDB` 트랜잭션의 GTID는 주기적으로 실행되는 GTID persister 스레드에 의해 `mysql.gtid_executed` 테이블로 플러시되는 반면, non-`InnoDB` 트랜잭션의 GTID는 레플리카 서버 스레드에 의해 `mysql.gtid_executed` 테이블에 직접 기록됩니다. GTID persister 스레드는 항목 병합과 `mysql.gtid_executed` 테이블 압축을 반복하는 동안 뒤처졌습니다. 그 결과 `InnoDB` 트랜잭션에 대한 GTID 플러시 목록의 크기가 `mysql.gtid_executed` 테이블의 gap 수와 함께 시간이 지나면서 증가했으며, 결국 서버 장애와 이후의 시작 실패를 유발했습니다. 이 문제를 해결하기 위해 이제 GTID persister 스레드는 `InnoDB` 및 non-`InnoDB` 트랜잭션 모두의 GTID를 기록하며, GTID persister 스레드가 뒤처지는 경우 포그라운드 커밋이 대기하도록 강제됩니다. 또한 [`gtid_executed_compression_period`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-gtids.html#sysvar_gtid_executed_compression_period) 기본 설정이 1000에서 0으로 변경되어, 기본적으로 `mysql.gtid_executed` 테이블의 명시적 압축을 비활성화했습니다.

  Venkatesh Prasad의 기여에 감사드립니다. (Bug #31599938, Bug #100118)
- **InnoDB:** XA 트랜잭션의 GTID 값을 영속화하는 작업이 XA 트랜잭션 성능에 영향을 주었습니다. XA 트랜잭션에 대해 두 개의 GTID 값이 생성되며, 하나는 prepare 단계용이고 다른 하나는 commit 단계용입니다. 첫 번째 GTID 값은 undo 로그에 기록되고 나중에 두 번째 GTID 값으로 덮어써집니다. 두 번째 GTID 값의 기록은 첫 번째 GTID 값을 `gtid_executed` 테이블에 플러시한 후에만 발생할 수 있었습니다. 이제 두 XA 트랜잭션 GTID 값 모두를 위한 공간이 undo 로그에 예약됩니다. (Bug #31467953, Bug #99638)
- **InnoDB:** Doxygen 소스 코드 문서를 빌드할 때 생성되는 경고를 처리하기 위해 `InnoDB` 소스 파일이 업데이트되었습니다. (Bug #31354760)
- **InnoDB:** 전체 텍스트 검색 동기화 스레드가 인덱스 캐시에서 이전에 해제된 단어를 읽으려고 시도했습니다. (Bug #31310404)
- **InnoDB:** MySQL 8.0.17의 병렬 읽기 기능과 함께 도입된 `buf_wait_for_read()` 함수의 20µs sleep이 Windows에서 1ms가 되어, 특정 테스트를 실행할 때 예상치 못한 timeout이 발생했습니다. 또한 AIO 스레드에 대기 중인 운영체제 IO 요청 수가 고르지 않은 것으로 확인되었습니다. (Bug #31095274)

  참조: 이 문제는 다음의 회귀입니다: Bug #31123564.

- **InnoDB:** 특정 복제된 XA 트랜잭션에서 정리 작업이 트랜잭션 객체(`trx_t`)를 다시 연결하지 못해 assertion failure가 발생했습니다. (Bug #31006095)
- **InnoDB:** 서버 장애 후 [`ALTER TABLESPACE ENCRYPTION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-tablespace.html) 작업을 재개하는 동안 발생한 실패로 인해 테이블스페이스 암호화 타입 설정이 올바르게 업데이트되지 않았습니다. (Bug #30883833, Bug #98537)
- **InnoDB:** 중단된 테이블스페이스 암호화 작업은 서버가 재시작된 후 작업이 처리를 재개할 때 데이터 딕셔너리의 `encrypt_type` 테이블 옵션 정보를 업데이트하지 않았습니다. (Bug #30883833, Bug #98537, Bug #30888919, Bug #98564)
- **InnoDB:** 스레드 sleep 지연 및 `InnoDB`에 진입하고 떠나는 스레드와 관련된 내부 카운터 변수는 C++ `std::atomic`을 사용하도록 개정되었습니다. 내장 atomic 작업은 제거되었습니다. 기여해 주신 ARM의 Yibo Cai에게 감사드립니다. (Bug #30567060, Bug #97704)
- **InnoDB:** 딕셔너리 메모리 변수 fetch-add(`dict_temp_file_num.fetch_add`) 및 store(`dict_temp_file_num.store`) 작업에 대해 relaxed memory order가 구현되었습니다.

  기여해 주신 Yibo Cai에게 감사드립니다. (Bug #30567054, Bug #97703)

- **InnoDB:** 서버가 시작된 후 테이블스페이스 암호화 작업을 재개한 백그라운드 스레드가 테이블스페이스에 대한 메타데이터 잠금을 획득하지 못했으며, 이로 인해 동시 DDL 작업이 허용되어 시작 스레드와의 경쟁 조건이 발생했습니다. 이제 시작 스레드는 테이블스페이스 메타데이터 잠금이 획득될 때까지 기다립니다. (Bug #28531637)
- **InnoDB:** `numa_all_nodes_ptr`에 대한 호출이 `numa_get_mems_allowed()` 함수로 대체되었습니다. 기여해 주신 Daniel Black에게 감사드립니다. (Bug #24693086, Bug #83044)
- **Partitioning:** `t1`이 파티셔닝된 테이블이 아닌 경우 [`ALTER TABLE t1 EXCHANGE PARTITION... WITH TABLE t2`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table-partition-operations.html)가 assert를 발생시켰습니다. (Bug #100971, Bug #31941543)

  참조: 이 문제는 다음의 회귀입니다: Bug #29706669.

- **Replication:** `asynchronous_connection_failover_add_source()` 및 `asynchronous_connection_failover_delete_source()` 함수의 `network_namespace` 매개변수는 더 이상 사용되지 않습니다. 이러한 함수는 비동기 연결 장애 조치 메커니즘을 위해 복제 채널의 소스 목록에 복제 소스 서버를 추가하고 제거합니다. 복제 채널의 네트워크 네임스페이스는 `CHANGE REPLICATION SOURCE` 문을 사용하여 관리되며, Group Replication 소스 서버에 대한 특별한 요구 사항이 있으므로, 더 이상 이 함수에서 지정해서는 안 됩니다. (Bug #32078189)
- **Replication:** **mysqlbinlog**의 `--print-table-metadata` 옵션을 사용할 때, **mysqlbinlog**는 숫자 필드를 평가하는 데 바이너리 로그에 쓸 때 서버가 사용하는 방법과 다른 방법을 사용했으며, 이로 인해 이러한 필드와 관련된 잘못된 메타데이터 출력이 발생했습니다. 이제 **mysqlbinlog**는 서버와 동일한 방법을 사용합니다. (Bug #31956206)
- **Replication:** 복제 채널에서 네트워크 네임스페이스를 사용하고 레플리카에서 마스터로의 초기 연결이 중단된 경우, 이후 연결 시도에서 올바른 네임스페이스 정보를 사용하지 못했습니다. (Bug #31954087)

- **Replication:** 그룹 멤버가 추방되고 인스턴스의 일부 테이블이 잠긴 시점(예: 백업이 실행 중인 동안)에 자동 재참여 시도를 수행한 경우, 해당 시도는 실패하고 추가 시도는 수행되지 않았습니다. 이제 이 시나리오는 올바르게 처리됩니다. (Bug #31460690)
- **Replication:** 반동기 소스 서버에서 복제하는 복제본 수가 증가함에 따라 잠금 경합으로 인해 성능 저하가 발생할 수 있었습니다. 플러그인에서 사용하는 잠금 메커니즘은 가능한 경우 공유 잠금을 사용하고, 불필요한 잠금 획득을 피하며, 콜백을 제한하도록 변경되었습니다. 새 동작은 다음 시스템 변수를 활성화하여 구현할 수 있습니다:

  - `replication_sender_observe_commit_only=1`은 콜백을 제한합니다.
  - `replication_optimize_for_static_plugin_config=1`은 공유 잠금을 추가하고 불필요한 잠금 획득을 피합니다. 플러그인을 제거하려는 경우 이 시스템 변수는 비활성화해야 합니다.

  두 시스템 변수는 반동기 복제 플러그인을 설치하기 전이나 후에 활성화할 수 있으며, 복제가 실행 중인 동안에도 활성화할 수 있습니다. 반동기 복제 소스 서버도 이러한 시스템 변수를 활성화함으로써 성능 이점을 얻을 수 있는데, 이는 복제본과 동일한 잠금 메커니즘을 사용하기 때문입니다. (Bug #30519928)

- **Replication:** 커밋 순서가 보존되는 멀티스레드 복제본에서는 워커 스레드가 자체 트랜잭션을 커밋하기 전에 relay log에서 더 앞서 발생한 모든 트랜잭션이 커밋될 때까지 기다려야 합니다. 커밋 순서상 나중에 있는 트랜잭션을 커밋하기 위해 대기 중인 스레드가 커밋 순서상 더 앞선 트랜잭션에 필요한 로우를 잠갔기 때문에 데드락이 발생하면, 데드락 감지 알고리즘은 대기 중인 스레드에 해당 트랜잭션을 롤백하라는 신호를 보냅니다. 이전에는 트랜잭션 재시도가 가능하지 않은 경우, 트랜잭션을 롤백한 워커 스레드가 커밋 순서에 있는 다른 워커 스레드에 신호를 보내지 않고 즉시 종료되어 복제가 정지될 수 있었습니다. 이제 이 상황의 워커 스레드는 롤백 함수를 호출할 차례가 될 때까지 기다리며, 이는 다른 스레드에 올바르게 신호를 보낸다는 의미입니다. (Bug #26883680, Bug #87796)

- **Replication:** GTID는 signed 64-bit integer의 음수가 아닌 값 개수(2의 63제곱에서 1을 뺀 값)까지만 서버 인스턴스에서 사용할 수 있습니다. [`gtid_purged`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-gtids.html#sysvar_gtid_purged) 값을 이 한계에 가까운 숫자로 설정하면, 이후 커밋으로 인해 서버의 GTID가 고갈되어 [`binlog_error_action`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_binlog_error_action)에서 지정한 조치를 수행할 수 있습니다. MySQL 8.0.23부터는 서버 인스턴스가 이 한계에 가까워질 때 경고 메시지가 발행됩니다. (Bug #26035544)

- **Group Replication:** MySQL 8.0의 기본값이며 Group Replication의 요구 사항인 시스템 변수 [`transaction_write_set_extraction=XXHASH64`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_transaction_write_set_extraction)가 설정된 경우, 이전에는 트랜잭션에 대한 쓰기 모음에 상한 크기 제한이 없었습니다. 이제 표준 소스-복제본 복제의 경우 [`binlog_transaction_dependency_history_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_binlog_transaction_dependency_history_size)로 지정된 쓰기 집합의 숫자 제한이 적용되며, 그 이후에는 쓰기 집합 정보가 폐기되지만 트랜잭션은 계속 실행됩니다. 그러면 쓰기 집합 정보를 의존성 계산에 사용할 수 없기 때문에 트랜잭션은 비동시로 표시되며, 복제본에서 순차적으로 처리됩니다. Group Replication의 경우 트랜잭션에서 쓰기를 추출하는 프로세스는 모든 그룹 멤버에서 충돌 감지 및 인증에 필요하므로, 트랜잭션이 완료되려면 쓰기 집합 정보를 폐기할 수 없습니다. 숫자 제한 대신 [`group_replication_transaction_size_limit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-system-variables.html#sysvar_group_replication_transaction_size_limit)로 설정된 바이트 제한이 적용되며, 제한을 초과하면 트랜잭션 실행에 실패합니다. (Bug #32019842)

- **Group Replication:** Group Replication applier 채널(`group_replication_applier`)이 예를 들어 진행 중인 백업 때문에 테이블에 대한 잠금을 보유하고 있었고, 해당 멤버가 그룹에서 추방된 후 자동으로 다시 참여하려고 한 경우, auto-rejoin 시도가 성공하지 못했으며 재시도하지 않았습니다. 이제 Group Replication은 시작 및 재참여 시도 중에 `group_replication_applier` 채널이 이미 실행 중인지 확인합니다. 시작 시 그 경우에 해당하면 오류 메시지가 반환됩니다. auto-rejoin 시도 중에 그 경우에 해당하면 해당 시도는 실패하지만, [`group_replication_autorejoin_tries`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-system-variables.html#sysvar_group_replication_autorejoin_tries) 시스템 변수로 지정된 대로 추가 시도가 수행됩니다. (Bug #31648211)
- **Microsoft Windows:** Windows에서 MySQL 서버를 서비스로 실행하면 공유 메모리 연결이 실패했습니다. (Bug #32009251)
- **JSON:** [`JSON_ARRAYAGG()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_json-arrayagg)는 항상 적절한 오류 처리를 수행하지는 않았습니다. (Bug #31856260, Bug #32012559, Bug #32181438)

- **JSON:** [`JSON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json.html) 값을 [`JSON_SET()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-set), [`JSON_REPLACE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-replace) 또는 [`JSON_REMOVE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-remove)를 사용하여 업데이트할 때, 대상 컬럼이 때때로 제자리에서 업데이트될 수 있습니다. 이는 업데이트 작업의 대상 테이블이 베이스 테이블인 경우에만 발생했지만, 대상 테이블이 업데이트 가능한 뷰인 경우에는 항상 전체 `JSON` 값을 기록하여 업데이트가 수행되었습니다.

  이제 이러한 경우 대상 테이블이 업데이트 가능한 뷰인 경우에도 제자리 업데이트(즉, 부분 업데이트)가 수행됩니다. (Bug #25840784)

- **JSON:** 준비된 명령문이 한 번만 준비되도록 MySQL 8.0.22에서 수행된 작업으로 인해 JSON 함수에 대한 동적 매개변수 처리에서 회귀가 도입되었습니다. 모든 [`JSON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json.html) 인자는 데이터 타입 `MYSQL_TYPE_JSON`으로 분류되었으며, 이는 JSON 함수가 JSON 값과 JSON 문서라는 두 종류의 JSON 매개변수를 받으며 이 구분은 데이터 타입만으로는 할 수 없다는 사실을 간과한 것입니다. Bug #31667405에 대해, 이 문제는 JSON 인자를 스칼라 값으로 태그할 수 있도록 하면서 다른 JSON 함수에 대한 인자는 JSON 문서로 처리되도록 함으로써 비교 연산자 및 [`IN()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/comparison-operators.html#operator_in) 연산자에 대해 해결되었습니다.

  현재 수정 사항은 여러 JSON 함수에 대해 특정 인자를 JSON 값으로 처리하던 동작을 복원하며, 그 목록은 다음과 같습니다:

  [`MEMBER OF()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-search-functions.html#operator_member-of)에 대한 첫 번째 인자

  [`JSON_INSERT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-insert), [`JSON_REPLACE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-replace), [`JSON_SET()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-set), [`JSON_ARRAY_APPEND()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-array-append), 및 [`JSON_ARRAY_INSERT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-modification-functions.html#function_json-array-insert) 함수에 대한 세 번째, 다섯 번째, 일곱 번째 및 그 이후의 홀수 번째 인자입니다. (Bug #101284, Bug #32063203)

  References: 참고: Bug #31667405도 참조하십시오.
- **JSON:** **mysqld**가 [`--debug`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-options.html#option_mysqld_debug)로 실행되었을 때, 다중 값 인덱스를 사용하는 쿼리를 실행하려고 시도하면 오류가 발생했습니다. (Bug #99833, Bug #31474182)
- `thread_pool` 플러그인을 사용하면 Address Sanitizer 경고가 발생할 수 있었습니다. (Bug #32213294)
- 구체화된 파생 테이블로 조건을 푸시다운하는 동안 조건이 부분적으로 푸시다운되고, 쿼리 변환이 `WHERE` 조건에 새 조건을 추가한 일부 경우에는 Optimizer가 외부 쿼리 블록에 남아 있는 조건에 대해 내부 `fix_fields()` 함수를 호출할 수 있었습니다. 이 함수 호출에서 성공적으로 반환된 것이 오류로 잘못 해석되어, 원래 명령문이 조용히 실패했습니다. (Bug #32150145)
- `ORDER BY` 절을 포함한 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문을 포함하는 저장 프로시저를 여러 번 호출하면 서버가 종료될 수 있었습니다. (Bug #32147402)
- 저장 프로그램과 관련된 prepared statement가 heap-use-after-free 메모리 문제를 일으킬 수 있었습니다. (Bug #32131022, Bug #32045681, Bug #32051928)

- 구체화된 파생 테이블이 관련된 [`INFORMATION_SCHEMA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema.html) 테이블에 대한 쿼리가 실패할 수 있었습니다. (Bug #32127562, Bug #101504)
- 잠재적 버퍼 오버플로가 수정되었습니다. 문제를 지적하고 수정 방안을 제안해 준 Sifang Zhao에게 감사드립니다(그 수정 방안은 사용되지 않았습니다). (Bug #32113015, Bug #101448)
- `FLOAT` 값을 `INT` 타입의 값으로 변환할 때 Undefined Behavior Sanitizer 경고가 생성될 수 있었습니다. (Bug #32099994, Bug #32100033)
- 여러 로우 쿼리에서 [`LOAD_FILE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_load-file) 함수가 모든 로우에 대해 같은 값으로 평가되었습니다. (Bug #32096341, Bug #101401)
- Generic Linux **tar** 파일 배포판은 압축 해제 후 파일 권한이 너무 제한적이어서, 이를 수정하려면 수동 **chmod**가 필요했습니다. (Bug #32080900)
- 디버그 빌드의 경우, 저장 프로시저에서 서브쿼리를 포함하는 준비된 [`SET`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set-variable.html) 문이 assertion을 발생시킬 수 있었습니다. (Bug #32078387)

  참조: 다음도 참조하십시오: Bug #32100210.
- 준비된 문에서, 적법한 콜레이션 혼합에 대해 illegal mix of collations 오류가 발생할 수 있었습니다. (Bug #32077842, Bug #101346, Bug #32145078, Bug #101575)

- `REGEXP_LIKE()`, `REGEXP_INSTR()`, `REGEXP_REPLACE()` 함수는 잘못된 형식의 정규식 패턴에 대해 오류를 발생시키지만, 이러한 경우에 `NULL`도 반환할 수 있어서 이후 debug assert가 발생했습니다. 이제 이러한 함수가 특정하게 지정된 경우를 제외하고 `NULL`을 반환하지 않도록 보장합니다.

  `REGEXP_SUBSTR()` 함수는 항상 `NULL`을 반환할 수 있으므로 이러한 검사가 필요하지 않으며, 이 함수에 대해서는 해당 검사가 수행되지 않도록 보장합니다. (Bug #32053093)
- `WITH ROLLUP`을 사용하는 `HAVING` 조건에서 집계 함수를 `IS NULL` 또는 `IS NOT NULL`로 테스트하면 잘못된 결과가 발생했습니다. (Bug #32049313)
- 내부 쿼리 블록에 현재 쿼리 블록에서 평가해야 하는 집계 함수가 있어서 새 집계 함수가 현재 쿼리 블록에 추가되었을 때, 서버가 필요에 따라 rollup wrapper를 추가하지 않았습니다. (Bug #32034914)
- debug 빌드의 경우, `CHECK` 제약 조건이 있는 특정 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html) 문에서 assertion이 발생할 수 있었습니다. (Bug #32018406, Bug #101180)
- secondary engine load 작업 중에 잘못된 BLOB 필드 값이 `InnoDB`에서 전달되었습니다. (Bug #32014483)
- LOCK_ORDER 도구가 `InnoDB` share exclusive lock을 올바르게 표현하지 않았습니다. (Bug #31994052)

- 서버는 hash join의 일부로 잘못된 컬럼 타입과 함께 집계 함수를 사용하려고 할 때 발생한 오류를 제대로 처리하지 못했습니다. (Bug #31989333)
- [`INFORMATION_SCHEMA.KEYWORDS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-keywords-table.html) 테이블의 `WORD` 컬럼 길이가 테이블 내용에 따라 변경될 수 있었습니다. (Bug #31982157)
- Performance Schema가 비활성화된 경우 Performance Schema `host_cache` 테이블이 비어 있었으며 호스트 캐시의 내용을 노출하지 않았습니다. 이제 이 테이블은 Performance Schema의 활성화 여부와 관계없이 캐시 내용을 표시합니다. (Bug #31978763)
- 이전 구문이 사용 후 `THD::mark_used_columns`의 원래 값을 복원하지 않은 경우, [`HANDLER READ`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/handler.html) 구문이 때때로 assert에 도달했습니다. (Bug #31977414)
- 압축된 테이블을 가져올 때 압축 해제 시 매우 큰 값이 테이블에 포함되어 있으면 예기치 않은 서버 종료가 발생할 수 있었습니다. (Bug #31943021)
- hash join과 `LIMIT`을 사용하는 서브쿼리가 반복적으로 실행될 때 발생할 수 있던 메모리 누수가 제거되었습니다. (Bug #31940549)
- Ubuntu에서 발생하던 컴파일 실패가 수정되었습니다. (Bug #31930934, Bug #100938)
- partial-revokes 정보를 저장하는 데 사용되는 메모리가 많은 수의 구문을 실행한 세션에서 과도하게 증가할 수 있었습니다. (Bug #31919448)

- 서버가 `WHERE_CONDITION` 최적화의 모든 경우를 올바르게 처리하지 못했습니다. (Bug #31905199)
- [`FLUSH TABLES WITH READ LOCK`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-tables-with-read-lock)이 다른 세션에서 [`SHOW TABLE STATUS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-table-status.html)를 실행하지 못하도록 차단할 수 있었습니다. (Bug #31894662)
- 일부 경우에 [`MIN()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_min) 및 [`MAX()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_max)가 시간 값 또는 [`JSON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json.html) 값을 인수로 사용하여 윈도우 함수로 사용될 때 잘못 `NULL`을 반환했습니다. (Bug #31882291)
- [`GRANT... GRANT OPTION... TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/grant.html) 및 [`GRANT... TO.. WITH GRANT OPTION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/grant.html)이 때때로 서버 로그에 올바르게 기록되지 않았습니다. (Bug #31869146, Bug #100793)
- 디버그 빌드의 경우, 256개를 초과하는 항목의 파티션 목록을 사용하는 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html)이 어설션을 발생시켰습니다. (Bug #31867653)

- [`init_file`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_init_file) 시스템 변수로 명명된 파일의 쿼리로 인해 서버 시작 실패가 발생할 수 있었습니다. (Bug #31835782)
- 해시 조인을 수행할 때 옵티마이저가 음수 정수 값과 매우 큰 unsigned 정수 값 사이의 잘못된 일치를 등록할 수 있었습니다. (Bug #31832001, Bug #31940639, Bug #100967)
- [`SHOW VARIABLES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-variables.html)가 [`partial_revokes`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_partial_revokes) 시스템 변수에 대해 잘못된 값을 보고할 수 있었습니다. (Bug #31819558, Bug #100677)
- Performance Schema [`user_defined_functions`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-user-defined-functions-table.html) 테이블에서 `UDF_LIBRARY` 컬럼 값은 서비스 API를 통해 등록된 로드 가능 함수에 대해 `NULL`이어야 합니다. 이 값이 빈 문자열로 잘못 설정되었습니다. (Bug #31791754)
- 서버 자동 업그레이드 절차가 `latin1` 캐릭터셋을 사용한 이전 help 테이블을 업그레이드하지 못했습니다. (Bug #31789964)
- serializable 또는 repeatable-read 트랜잭션 격리 수준에서 grant 테이블을 읽는 SQL 문을 실행할 때 중복 경고가 발생할 수 있었습니다. (Bug #31769242)

- `DISTINCT` 집계가 포함된 특정 쿼리(일반적으로 집계 전에 정렬하여 해결됩니다)에서 서버는 임시 테이블을 처리하는 로직이 중복 제거를 수행한다는 잘못된 가정으로 인해 스트리밍 대신 임시 테이블을 사용했습니다. 이제 서버는 대신 암시된 유니크 인덱스를 확인하며, 이는 더 견고하고 불필요한 로직을 제거할 수 있게 합니다. (Bug #31762806)
- Event Scheduler 이벤트 정의에서 [`lower_case_table_names`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_lower_case_table_names) 값과 스키마 이름의 특정 조합이 서버를 정지시킬 수 있었습니다. (Bug #31733090)
- 하나의 저장 함수 내부에서 다른 저장 함수를 호출하면 필드 해석에서 충돌이 발생하여 서버 종료가 발생할 수 있었습니다. (Bug #31731334)
- `udf_init()` 메서드 없이 정의된 로드 가능 함수가 예기치 않은 서버 종료를 유발할 수 있었습니다. (Bug #31701219)
- [`secure_file_priv`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_secure_file_priv) 시스템 변수를 `NULL`로 설정하면 해당 동작을 비활성화해야 하지만, 대신 서버가 `NULL`이라는 이름의 디렉터리를 생성하게 했습니다. (Bug #31700734, Bug #100384)
- **mysqlpump**는 공유 구조에 대한 부적절한 동시 접근으로 인해 예기치 않게 종료될 수 있었습니다. (Bug #31696241)

- 컴포넌트를 제거하고 해당 컴포넌트가 설치한 loadable function을 등록 해제하는 작업이 해당 함수가 현재 사용 중인지 여부와 적절히 동기화되지 않았습니다. (Bug #31646698)
- 다중 테이블 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html) 또는 [`DELETE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/delete.html)를 수행한 prepared statement 실행 후 정리가 항상 올바르게 수행되지는 않았으며, 이로 인해 그러한 prepared statement의 첫 번째 실행 후 실제로 변경된 로우가 없었음에도 서버가 업데이트된 로우 수를 0이 아닌 값으로 보고했습니다. (Bug #31640267)

  참조: 다음도 참조하십시오: Bug #32100210.
- primary key extension을 지원하는 엔진의 경우, 전체 키 길이가 `MAX_KEY_LENGTH`를 초과하거나 키 파트 수가 `MAX_REF_PARTS`를 초과하면 이러한 제한 안에 맞지 않는 primary key의 키 파트는 secondary key에 추가되지 않았지만, primary key의 키 파트는 무조건 secondary key의 일부로 표시되었습니다.

  이로 인해 secondary key가 covering index로 처리되는 상황이 발생했으며, 이는 때때로 잘못된 접근 방법이 선택되었음을 의미했습니다.

  이는 primary key의 키 파트를 secondary key에 추가하는 방식을 수정하여 앞서 언급한 제한 안에 맞지 않는 항목이 지워지도록 함으로써 수정되었습니다. (Bug #31617858)

- MySQL이 [`-DWITH_ICU=system`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/source-configuration-options.html#option_cmake_with_icu)으로 설정된 경우, **CMake**는 이제 ICU 라이브러리 버전이 충분히 최신인지 확인합니다. (Bug #31600044)
- [`--binary-as-hex`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysql-command-options.html#option_mysql_binary-as-hex) 옵션과 함께 호출된 경우, **mysql**은 `NULL` 값을 빈 바이너리 문자열(`0x`)로 표시했습니다.

  정의되지 않은 변수를 선택하면 `NULL`이 아니라 빈 바이너리 문자열(`0x`)이 반환되었습니다. (Bug #31549724, Bug #31638968, Bug #100251)
- `DISABLE_PSI_xxx` Performance Schema 관련 **CMake** 옵션을 활성화하면 빌드 실패가 발생했습니다. (Bug #31549724)
- 일부 쿼리는 [`internal_tmp_mem_storage_engine`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) 값에 따라 서로 다른 결과를 반환했습니다.

  이 문제의 근본 원인은 윈도우 함수용 로우를 버퍼링할 때, 이러한 버퍼링된 로우를 보관하는 인메모리 임시 테이블의 크기가 지정된 제한을 초과하면 새 임시 테이블이 디스크에 생성된다는 사실과 관련이 있었습니다. 프레임 버퍼 파티션 오프셋은 새 파티션의 시작 지점에서 지금까지 읽은 총 로우 수로 설정되며, 임시 테이블이 디스크로 이동될 때 사용되도록 특별히 업데이트됩니다(이는 윈도우 함수를 처리하는 데 필요한 힌트를 계산하는 데 사용됩니다). 문제는 디스크에 임시 테이블을 생성하는 동안 새 파티션이 시작되는 특정 경우에 프레임 버퍼 파티션 오프셋이 업데이트되지 않아, 잘못된 로우가 읽히게 되었기 때문에 발생했습니다.

  이 문제는 임시 테이블이 디스크로 이동되는 동안 새 파티션이 시작될 때마다 프레임 버퍼 파티션 오프셋을 올바르게 업데이트하도록 하여 해결되었습니다. (Bug #31546816)
- 윈도우 함수에 사용할 로우를 버퍼링하는 동안, 이러한 버퍼링된 로우를 보관하는 메모리 내 임시 테이블의 크기가 [`temptable_max_ram`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_temptable_max_ram)에 지정된 제한을 초과하면 새 임시 테이블이 디스크에 생성됩니다. 임시 테이블이 생성된 후에는 임시 테이블이 이제 디스크로 이동되어 기존 힌트를 사용할 수 없게 되므로, 윈도우 함수를 처리하는 데 사용되는 힌트를 재설정해야 합니다. 디스크에 임시 테이블을 생성하는 작업이 프레임 버퍼의 첫 번째 로우를 처리하는 중에 발생하면, 힌트가 초기화되지 않았으며 이렇게 초기화되지 않은 힌트를 재설정하려고 하면 계획되지 않은 서버 종료가 발생했습니다.

  이 문제는 프레임 버퍼 힌트를 재설정하기 전에 해당 힌트가 초기화되었는지 확인하는 검사를 추가하여 해결되었습니다. (Bug #31544404)
- `CHANNEL_NAME`의 인덱스가 `USE INDEX ()`로 비활성화된 경우, Performance Schema가 `CHANNEL_NAME` 컬럼에 대한 조인에서 잘못된 결과를 생성할 수 있었습니다. (Bug #31544023, Bug #99989)
- 사용되지 않는 윈도우 정의를 제거할 때, `ORDER BY`의 일부였던 서브쿼리가 제거되지 않았습니다. (Bug #31518806)

- 특정 경우 서버가 여러 겹으로 중첩된 서브쿼리를 올바르게 처리하지 못했습니다. (Bug #31472704)
- [`VALUES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/values.html) 문에 대해 인식되는 문법에는 `ORDER BY` 절이 포함되지만, 이 절이 해석되지 않아 실행 엔진이 유효하지 않은 데이터를 만날 수 있었습니다. (Bug #31387510)
- 서버가 시작 시 존재하지 않는 임시 디렉터리에 접근하려고 시도하여 실패가 발생했습니다. 임시 디렉터리가 존재하는지와 파일이 [`tmpdir`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_tmpdir) 디렉터리에 성공적으로 생성되는지 확인하는 검사가 추가되었습니다. (Bug #31377118)
- 중복 정렬을 제거하는 동안, 다른 window의 정렬 때문에 로우가 순서대로 들어올 것으로 예상되었다는 사실로 인해 한 window의 정렬이 제거되었습니다. 이후 다른 window가 사용되지 않아 제거되었을 때, 이로 인해 순서가 지정되지 않은 로우가 발생했으며, 이는 평가 중 예상되지 않은 동작이었습니다.

  이제 이러한 경우 사용되지 않는 window가 제거된 후에야 중복 sort 제거가 수행됩니다. 또한 모든 rollup 해석이 준비 단계로 이동되었습니다. (Bug #31361393)

- Semisynchronous 복제 오류가 오류 로그에 `Server`라는 서브시스템 태그와 함께 잘못 기록되었습니다. 이제 다른 복제 오류와 동일하게 `Repl` 태그와 함께 기록됩니다. (Bug #31327337)
- 사용자가 자신을 자신에게 역할로 부여할 수 있었습니다. (Bug #31222230)
- 서버가 여러 `WHERE` 조건 중 하나가 항상 FALSE이고, 이러한 조건들이 동일한 서브쿼리를 참조하는 경우를 항상 올바르게 처리하지는 못했습니다. (Bug #31216115)
- [`lower_case_table_names=2`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_lower_case_table_names) 설정에서 `InnoDB` 백그라운드 스레드가 잠금 키의 스키마 이름 부분에 잘못된 문자 대소문자를 사용하여 테이블 메타데이터 잠금을 획득하는 경우가 있었으며, 이로 인해 보호되지 않은 메타데이터와 경합 조건이 발생했습니다. 이제 올바른 문자 대소문자가 적용됩니다. 해당 데이터 딕셔너리 객체보다 먼저 메타데이터 잠금이 해제되지 않도록 방지하고, 데이터 딕셔너리 객체를 획득할 때 잠금 보호를 확인하는 assertion 코드를 개선하기 위한 변경도 구현되었습니다. (Bug #31165802)
- [`CR_UNKNOWN_ERROR`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/client-error-reference.html#error_cr_unknown_error)가 클라이언트로 전송될 예정인 경우 예외가 발생했습니다. (Bug #31123643)

- `DOUBLE` 값을 `BIT`, `ENUM` 또는 `SET` 타입 값으로 변환할 때 Undefined Behavior Sanitizer 경고가 생성될 수 있었습니다. (Bug #31019130)
- [`skip_name_resolve`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_skip_name_resolve) 시스템 변수가 활성화된 경우 특정 계정으로 인해 서버 시작 실패가 발생할 수 있었습니다. (Bug #31018510)
- 통신 패킷에 잘못된 데이터가 포함된 경우 클라이언트 프로그램이 예기치 않게 종료될 수 있었습니다. (Bug #30890850)
- 클라이언트 라이브러리의 버퍼 오버플로가 수정되었습니다. (Bug #30885987)
- 다중 값 인덱스 또는 기타 함수형 인덱스를 생성할 때, 인덱스 자체가 실제로 사용되지 않았음에도 해당 인덱스가 정의된 테이블에 대해 쿼리를 실행하면 성능 저하가 나타났습니다. 이는 이러한 인덱스를 지원하는 숨겨진 가상 컬럼이 쿼리의 각 로우에 대해 불필요하게 평가되었기 때문에 발생했습니다. (Bug #30838749)

  참고: 이 문제는 다음의 회귀입니다: Bug #28069731.
- `libcurl` 의존성에 대한 **CMake** 검사가 개선되었습니다. (Bug #30268245)
- **mysql_config_editor**가 패스워드 값의 `#`을 주석 문자로 잘못 처리했습니다. (Bug #29861961, Bug #95597)
- 일부 경우에 Optimizer가 빈 문자열에 대한 해시 값을 계산하려고 시도했습니다. 이제 대신 항상 고정 값이 사용됩니다. (Bug #22588319)

- [`INSERT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_insert) 및 [`RPAD()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_rpad) 함수가 결과의 캐릭터셋을 올바르게 설정하지 않았습니다. (Bug #22523946, Bug #79909, Bug #31887870, Bug #100841)
- `val1 BETWEEEN val2 AND val3`에 대한 일부 코너 케이스가 수정되었으며, 예를 들어 `-1 BETWEEN 9223372036854775808 AND 1`이 true를 반환했습니다. (Bug #22515857, Bug #79878)
- Performance Schema [`memory_summary_global_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-memory-summary-tables.html) 테이블의 경우, low watermark 컬럼이 음수 값을 가질 수 있었고, high watermark 컬럼은 서버 메모리 사용량이 증가하지 않는 경우에도 계속 증가하는 값을 가졌습니다. (Bug #22246001, Bug #79285)
- 문자열을 숫자로 변환하는 여러 문제가 수정되었습니다. (Bug #19186271, Bug #73248)
- 올바르게 수행되던 특정 group by 쿼리는 `WITH ROLLUP`이 추가되면 예상한 결과를 반환하지 않았습니다. 이는 decimal 정보가 rollup group 항목을 통해 항상 올바르게 전달되지 않아, [`TRUNCATE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mathematical-functions.html#function_truncate)와 같이 decimal 값을 반환하는 함수가 잘못된 타입의 데이터를 받게 되었기 때문입니다. (Bug #101684, Bug #32179240)

- 임시 테이블을 구체화하기 위한 필드를 생성할 때(즉, 조인을 정렬해야 할 때), Optimizer는 항목을 복사해야 하는지 또는 단순히 상수인지 확인합니다. 이는 하나의 특정한 경우에 올바르게 수행되지 않았습니다. 상수를 포함하는 뷰 또는 파생 테이블에 대해 외부 조인을 수행할 때 해당 항목이 테이블 안으로 제대로 구체화되지 않았으며, 이로 인해 결과에 `NULL`이 허위로 나타날 수 있었습니다. (Bug #101622, Bug #32162862)

  References: 함께 참조하십시오: Bug #31790217.
- [`REGEXP_REPLACE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/regexp.html#function_regexp-replace)가 SQL 문에서 사용되었을 때, 내부 함수 `Regexp_engine::Replace()`가 레코드를 처리한 후 오류 코드 값을 재설정하지 않았으며, 이는 다음 레코드의 처리에 영향을 줄 수 있었고 문제로 이어졌습니다.

  기여해 주신 Hope Lee님께 감사드립니다. (Bug #101256, Bug #32050219)
- 다음 형식을 가진 쿼리의 경우, 임시 테이블이 생성된 후 컬럼 목록이 때때로 일관되지 않은 상태를 가정하여, 나중에 범위를 벗어난 인덱싱이 발생했습니다:

  ```
  SELECT * FROM (
      SELECT PI()
      FROM t1 AS table1, t1 AS table2
      ORDER BY PI(), table1.a
  ) AS d1;
  ```

  (Bug #101012, Bug #31955761, Bug #31978439)

  References: 이 문제는 다음의 회귀입니다: Bug #31790217.

- 이미 정렬된 데이터에 대해 집계를 수행할 때(임시 테이블이 사용되지 않기 때문에 스트리밍 집계 수행이라고 알려져 있습니다), 다음 그룹의 첫 번째 로우를 처리할 때까지 그룹이 언제 끝났는지 확인할 수 없었으며, 그 시점에는 출력할 그룹 표현식이 이미 덮어써진 경우가 많았습니다.

  이 문제는 이전에 사용되던 복잡한 로직을, 그룹을 처음 만날 때 해당 그룹의 대표 로우를 저장하는 훨씬 더 단순한 방식으로 대체하여 수정되었습니다. 따라서 필요할 때 출력 로우에 대해 해당 컬럼을 쉽게 가져올 수 있습니다. (Bug #100791, Bug #27272052, Bug #31073167, Bug #31790217, Bug #31868610)
- fulltext matching을 사용하는 서브쿼리는 [`subquery_to_derived`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/switchable-optimizations.html#optflag_subquery-to-derived)가 활성화된 경우 제대로 수행되지 않을 수 있었으며, debug 빌드에서 assert로 이어질 수 있었습니다. (Bug #100749, Bug #31851600)

- [`ALTER TABLE... CONVERT TO CHARACTER SET`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문이 실행되면, 테이블에 있는 모든 [`CHAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/char.html), [`VARCHAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/char.html), [`TEXT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/blob.html) 컬럼의 캐릭터셋이 새 `CHARACTER SET` 값으로 업데이트됩니다. 이 변경 사항은 다중 값 인덱스에 대한 `ARRAY` 컬럼에서 사용되는 숨겨진 `CHAR` 컬럼에도 적용되었습니다. 숨겨진 컬럼의 캐릭터셋은 `my_charset_utf8mb4_0900_bin` 또는 `binary` 중 하나여야 하므로, 이로 인해 서버의 디버그 빌드에서 assert가 발생했습니다.

  이 문제는 앞에서 참조한 `ALTER TABLE` 문을 실행할 때 숨겨진 컬럼의 캐릭터셋을 더 이상 테이블의 캐릭터셋으로 설정하지 않도록 하여 해결되었습니다. 이는 유사한 상황에서 [`BLOB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/blob.html) 컬럼에 대해 수행되는 방식과 유사합니다. (Bug #99403, Bug #31301101)
- 일부 경우에 서버의 내부 문자열 변환 루틴은 길이 지정자를 사용하고 과학적 표기법 사용을 트리거한 부동 소수점 값을 처리하는 데 문제가 있었습니다. (Bug #92537, Bug #101570, Bug #28691605, Bug #32144265)

  참조: 함께 참조하십시오: Bug #88256, Bug #27041543.