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

## DBA를 위한 핵심 내용

MySQL 8.0.28은 TLS 구버전 제거, 감사/권한 복구 수단 추가, Performance Schema CPU 계측, 연결 메모리 제한 등 보안·관측·자원 제어 변화가 많습니다. 외부적으로는 Google Cloud가 MySQL 8.0.16~8.0.28의 range optimizer 메모리 증가/OOM 가능성을 알려 8.0.29 이상 업그레이드를 권고합니다. 따라서 8.0.28 도입 또는 유지 시에는 TLS 호환성뿐 아니라 메모리 사용 패턴과 패키지 서명 키 갱신 문제까지 함께 점검해야 합니다. ([Google Cloud known issues](https://docs.cloud.google.com/sql/docs/mysql/known-issues-in-mysql-8.0-minor-versions))

1. TLSv1/TLSv1.1 지원이 제거되었습니다. 서버, 클라이언트, 복제 채널, Group Replication recovery 설정의 `tls_version`, `admin_tls_version`, `SOURCE_TLS_VERSION`이 TLSv1.2 이상을 사용하도록 사전 확인해야 합니다.
2. MySQL GnuPG 빌드 키가 갱신되어 APT/YUM 저장소 업그레이드 시 서명 검증 오류가 발생할 수 있습니다. 자동 패치 파이프라인은 저장소 설정 패키지 재설치 또는 공개 키 갱신 절차를 포함해야 합니다.
3. Performance Schema에 `CPU_TIME`/`SUM_CPU_TIME`, sys 스키마에 `CPU_LATENCY`가 추가되어 쿼리 CPU 분석이 쉬워졌습니다. 단 `events_statements_cpu`는 기본 비활성화이므로 운영 관측 표준에 맞게 활성화 여부와 오버헤드를 검증해야 합니다.
4. `global_connection_memory_tracking`, `connection_memory_limit`, `global_connection_memory_limit`가 추가되어 사용자/전역 연결 메모리 사용량을 제한할 수 있습니다. 과도하게 낮은 값은 일반 사용자 쿼리 실패를 유발할 수 있으므로 root 우회 운영을 만들지 않도록 정책화가 필요합니다.
5. `CONVERT()` 반환 길이 계산 수정, `DATE_ADD()`/prepared statement 타입 결정 변경, generated column 인덱스 재생성 필요 가능성 등 SQL 호환성 영향이 있습니다. generated column, JSON/TEXT 정렬, prepared statement 중심 애플리케이션은 회귀 테스트를 권장합니다.

## Audit Log 관련 사항

- 새로운 [`audit_log_disable`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-reference.html#sysvar_audit_log_disable) 시스템 변수는 연결 중이거나 연결된 모든 세션에 대해 감사 로깅을 비활성화할 수 있게 합니다. [감사 로깅 비활성화](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-disabling.html)를 참조하십시오. (WL #14699)

## C API 관련 사항

- Windows에서 Clang을 컴파일러로 사용하여 C API 클라이언트 프로그램을 빌드하면 사용되지 않는 변수 경고를 포함한 다양한 컴파일러 경고가 반환되었습니다. (Bug #33520805, Bug #33520861)

## 캐릭터셋 지원

- **호환되지 않는 변경:** [`CONVERT(string USING charset)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_convert)는 반환 값의 올바른 최대 길이를 계산하지 않았으며, 이는 [`CAST(string AS charset)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_cast)에 대해 계산되는 값과 같아야 합니다. 이는 잘못된 것으로 거부되어야 했던 [`BINARY`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/binary-varbinary.html)에서 nonbinary 캐릭터셋으로의 일부 문자열 변환이 대신 값을 반환했음을 의미합니다.

  업그레이드하기 전에, 이전 `CONVERT()` 동작에 의존할 수 있는 애플리케이션을 확인하고 필요에 따라 업데이트해야 합니다. 특히 잘못된 값과 함께 `CONVERT()`를 사용하는 generated 컬럼의 인덱스의 경우, 이 릴리스로 업그레이드하기 전에 해당 값을 수정하고, 인덱스를 삭제한 다음, 다시 생성해야 합니다. 경우에 따라 인덱스를 삭제하고 다시 생성하는 대신 [`ALTER TABLE table FORCE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html)를 사용하여 테이블을 다시 빌드하는 것이 더 간단할 수 있습니다. 자세한 내용은 [SQL Changes](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/upgrading-from-previous-series.html#upgrade-sql-changes)를 참조하십시오. (Bug #33199145)
- [`EXPLAIN FORMAT=TREE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-execution-plan)의 출력은 데이터 타입이 바이너리가 아닌 경우에도 multi-valued 인덱스의 범위를 16진수로 인코딩했습니다. 또한 문자열 타입을 사용하는 범위도 바이너리 콜레이션을 가진 경우 16진수로 인코딩된 값으로 출력되었습니다. 후자의 문제는 일반 인덱스에도 영향을 주었지만, multi-valued 인덱스에서 더 잘 보였는데, 이는 이러한 인덱스가 항상 `utf8mb4_0900_bin` 콜레이션을 사용하기 때문입니다. 이제 16진수 인코딩은 바이너리 캐릭터셋을 가진 문자열 타입에만 사용됩니다. non-binary 캐릭터셋을 가진 문자열은 이제 `EXPLAIN FORMAT=TREE` 출력에서 일반 텍스트로 출력되며, 특수 문자는 이스케이프됩니다. (Bug #33343948)
- 일부 함수의 경우, 해석된 캐릭터셋이 항상 첫 번째 인수의 캐릭터셋과 같지는 않았습니다. (Bug #32668730, Bug #33238711)

## 컴파일 관련 사항

- **InnoDB:** 다음 MSVC++ level 4 컴파일러 경고와 관련된 컴파일 문제가 해결되었습니다: C4201, C4701, C4702, C4703, C4706. 이전에 비활성화되었던 컴파일러 경고가 이제 활성화되었습니다. (Bug #33464699)
- **InnoDB:** MSVC++ level 4 컴파일러 경고가 활성화되었습니다. (Bug #33437498)
- **InnoDB:** Visual Studio 2019 버전 16.10 또는 버전 16.11을 사용하여 MySQL의 디버그 버전을 빌드할 때 액세스 위반이 발생했습니다. 이 위반은 STL iterator 버그로 인한 것이었습니다. (Bug #33223243)
- 시스템 curl 라이브러리에 링크하는 대신 curl을 포함하는 바이너리 패키지가 curl 7.80.0을 사용하도록 업그레이드되었습니다. (Bug #33576431)

## 데이터 타입 관련 사항

- 이 릴리스는 날짜 및 시간 값과 관련된 다음 두 가지 문제를 수정합니다:

  - `'12:00:00'`과 같은 [`CHAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/char.html) 값을 [`DATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html), [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 또는 [`TIMESTAMP`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 컬럼에 삽입하면 잘못된 오류가 발생했습니다. `DATE` 컬럼의 경우 이 오류는 Data truncation: Incorrect date value: '2012-00-00' for column 'd' at row 1과 유사했습니다. 이는 바이너리 및 텍스트 프로토콜 모두에서 발생했습니다.
  - 바이너리 프로토콜을 사용하여 오프셋이 있는 값을 [`DATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 또는 [`TIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/time.html) 컬럼에 삽입하면 잘못된 결과가 제공되었습니다. 예를 들어 연결 시간대가 GMT-5로 설정된 경우 `'2021-10-10 00:00:00.123+01:00'`을 `TIME` 컬럼에 삽입하면 `'18:00:00'`이 산출되었습니다. 즉, 값이 연결 시간대로 변환되었습니다(이는 `DATETIME` 컬럼에 대해서만 수행되어야 합니다).

  시간대 오프셋이 있는 `TIMESTAMP` 값이 `TIME` 또는 `DATE` 컬럼에 삽입될 때마다 시간대 오프셋을 인식하고 이에 맞게 조정하여 이러한 문제를 수정합니다. (Bug #33616957, Bug #33649009)

  참조: 다음도 참조하십시오: Bug #33539844.
- 이전 문제에 대한 MySQL 8.0.27의 수정은 타입 처리를 단순화하기 위해 불리언 표현식의 해석된 타입을 signed [`INT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/integer-types.html)에서 unsigned [`BIGINT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/integer-types.html)로 변경했지만, 당시에는 무해한 메타데이터 변경으로 보였던 것이 일부 MySQL Connectors에 문제를 일으키는 것으로 드러났습니다.

  이제 메타데이터 변경을 되돌리고, 정수의 부정에 대한 `max_length`를 최소 두 문자로 조정하여 원래 문제에 대해 다른 수정을 제공합니다. (Bug #33516898)

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

- [`JSON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json.html) 및 [`TEXT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/blob.html)를 포함한 일부 컬럼 타입의 정렬은 정렬 버퍼 크기가 정렬에서 가장 큰 로우 크기의 최소 15배가 아니면 때때로 정렬 버퍼를 모두 소진했습니다. 이제 정렬 버퍼는 가장 큰 정렬 키의 15배 크기이면 됩니다. (Bug #103325, Bug #105532, Bug #32738705, Bug #33501541)

  참고: 이 문제는 다음의 회귀입니다: Bug #30400985, Bug #30804356.

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

- TLS v1.0 및 TLS v1.1 연결 프로토콜에 대한 지원은 MySQL 8.0.28부터 제거되었습니다. 이 프로토콜은 MySQL 8.0.26부터 사용 중단되었습니다. 배경 정보는 IETF 메모 [Deprecating TLS v1.0 and TLSv 1.1](https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html)을 참조하십시오. 더 안전한 TLSv1.2 및 TLSv1.3 프로토콜을 사용하여 연결하십시오. TLSv1.3은 MySQL Server 소프트웨어와 클라이언트 애플리케이션이 모두 OpenSSL 1.1.1 이상으로 컴파일되어 있어야 합니다.

  MySQL 8.0.28부터 MySQL Shell을 포함하여 MySQL 서버에 대한 연결에 사용할 TLS 프로토콜을 지정하는 `--tls-version` 옵션을 지원하는 클라이언트 프로그램은 프로토콜을 TLSv1 또는 TLSv1.1로 설정하여 TLS/SSL 연결을 만들 수 없습니다. 클라이언트가 이러한 프로토콜을 사용하여 연결을 시도하는 경우, TCP 연결에서는 연결이 실패하고 클라이언트에 오류가 반환됩니다. 소켓 연결에서는 `--ssl-mode`가 REQUIRED로 설정되어 있으면 연결이 실패하며, 그렇지 않으면 연결이 이루어지지만 TLS/SSL은 비활성화됩니다.

  서버 측에서는 MySQL 8.0.28부터 다음 설정이 변경되었습니다:

  - [`tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_tls_version) 및 [`admin_tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_admin_tls_version)에 허용되는 값에는 더 이상 `TLSv1` 또는 `TLSv1.1`이 포함되지 않습니다.
  - [`group_replication_recovery_tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-system-variables.html#sysvar_group_replication_recovery_tls_version)에 허용되는 값에는 더 이상 `TLSv1` 또는 `TLSv1.1`이 포함되지 않습니다.
  - 비동기 복제의 경우, 레플리카는 더 이상 소스 서버에 대한 연결 프로토콜([`CHANGE REPLICATION SOURCE TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html)의 `SOURCE_TLS_VERSION` 옵션)을 `TLSv1` 또는 `TLSv1.1`로 설정할 수 없습니다.

  (WL #14775)

- `CHARACTER SET latin1`의 단축 표기인 `ASCII`와 `CHARACTER SET ucs2`의 단축 표기인 `UNICODE`는 이제 사용 중단되었으며, 향후 MySQL 버전에서 제거될 것으로 예상해야 합니다. 이제 이들 중 하나를 사용하면 경고가 발생합니다. 대신 `CHARACTER SET`을 사용하십시오. (WL #13146)
- 여기에 나열된 캐릭터셋은 해당 캐릭터셋의 모든 콜레이션과 함께 이제 사용 중단되었으며, 이후 MySQL 릴리스에서 제거될 수 있습니다:

  - `ucs2`
  - `macroman` 및 `macce`
  - `dec`
  - `hp8`

    이제 이러한 캐릭터셋이나 해당 콜레이션을 SQL 문 또는 MySQL 서버의 다른 위치에서 사용하면 사용 중단 경고가 생성됩니다.

  방금 나열한 캐릭터셋 대신 `utf8mb4`를 사용해야 합니다. [The ucs2 Character Set (UCS-2 Unicode Encoding)](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/charset-unicode-ucs2.html), [West European Character Sets](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/charset-we-sets.html) 및 [Central European Character Sets](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/charset-ce-sets.html)도 참조하십시오. (WL #13594, WL #13595, WL #13596, WL #13597)

## Event Scheduler 관련 사항

- 이전 편의 기능으로, 서버는 [`super_read_only`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_super_read_only) 시스템 변수가 비활성화될 때 필요에 따라 Event Scheduler를 자동으로 다시 시작했습니다. 이제 이와 동일한 편의 기능이 [`read_only`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_read_only) 시스템 변수가 비활성화될 때 독립적으로 적용됩니다. 이 업데이트 이전에는 [`read_only`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_read_only)를 비활성화하면 필요한 경우 [`super_read_only`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_super_read_only)도 비활성화될 수 있었지만, 코드가 별도로 분리되어 있었기 때문에 Event Scheduler가 다시 시작되지 않았습니다. (Bug #33539082)

## Full-Text Search 관련 사항

- 구현된 방식상 [`MATCH()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/fulltext-search.html#function_match)는 해당 인수의 함수로 동작하지 않고, 오히려 베이스 테이블의 기본 스캔에서 현재 로우의 로우 ID에 대한 함수로 동작한다는 사실로 인해, 롤업 컬럼을 이 함수의 인수로 사용하는 쿼리는 성능이 낮고 결과를 신뢰하기 어려운 경향이 있었습니다. 이러한 경우에 해당하므로, 다음 조건이 참일 때마다 `MATCH()`와 함께 롤업 컬럼을 사용하는 것은 더 이상 허용되지 않습니다:

  - `MATCH()`가 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 목록, `GROUP BY` 절, `HAVING` 절 또는 `ORDER BY` 절에 나타납니다.
  - 쿼리가 `GROUP BY... WITH ROLLUP`을 사용합니다.
  - 그룹화 컬럼이 `MATCH()`의 인수로 사용됩니다.

  이제 이러한 쿼리는 모두 [`ER_FULLTEXT_WITH_ROLLUP`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_fulltext_with_rollup)와 함께 거부됩니다. (`WHERE` 절에서 롤업 컬럼과 함께 `MATCH()`를 사용하는 것은 이 변경의 영향을 받지 않으며, 여전히 허용됩니다.)

  자세한 내용은 [Full-Text Search Functions](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/fulltext-search.html)를 참조하십시오. (Bug #32565923, Bug #32996762, WL #14697)

## SQL 함수 및 연산자 관련 사항

- **중요한 변경:** prepared statement를 사용할 때, 계산에 [`YEAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/year.html), `MONTH` 또는 `DAY` 부분의 조합만 포함된 경우에도(즉, 시간 부분이 없는 경우에도) [`DATE_ADD()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_date-add) 및 [`DATE_SUB()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_date-sub) 함수가 [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 값을 반환했습니다.

  MySQL 8.0.22에서 prepared statement의 단일 준비를 구현하기 전에는 이러한 경우 [`TIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/time.html) 값이 반환되었습니다. 이 작업이 수행되기 전에는 `DATE_ADD()`, `DATE_SUB()`, [`ADDTIME()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_addtime) 같은 특정 시간 함수의 결과 타입을 해석 시점에 결정하는 데 인수로 사용된 값과 그 타입이 사용되었습니다. 이후에는 사용자 변수 참조와 동적 매개변수가 한 번의 실행 수명 동안에만 상수로 간주되므로, 반환 타입을 다른 방식으로, 이 경우 함수 타입에서 결정해야 합니다. 예를 들어 `DATE_ADD()`의 기본 해석 타입은 첫 번째 인수가 동적 매개변수인 경우 `DATETIME`으로 간주되었는데, 이는 `DATETIME`이 모든 시간 값을 수용하므로 암시적 재준비를 피할 수 있기 때문입니다.

  방금 설명한 변경은 회귀를 나타냅니다. 이 문제는 더 정밀하게 해석된 데이터 타입을 도출하고, 그것이 매개변수의 실제 값과 일치하지 않는 경우에만 재준비를 수행하는 방식으로 더 잘 해결됩니다. (이러한 기능은 숫자 매개변수에 대해 MySQL 서버에서 이미 사용되고 있었습니다.) 이 수정으로 이 해결 방법이 구현되었습니다.

  이제 시간 값이 예상되는 경우 문자열 및 숫자 값을 파싱합니다. 유효한 시간 값이 발견되면 해당 값이 변환됩니다. 이 수정은 또한 시간 함수에 대해 해석된 데이터 타입의 결정을 개선합니다.

  이 수정으로 `DATE_ADD()` 및 `DATE_SUB()` 함수(그리고 그 동의어 함수인 [`ADDDATE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_adddate) 및 [`SUBDATE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_subdate))는 타입을 다음과 같이 해석합니다:

- 첫 번째 인수가 동적 파라미터인 경우, 두 번째 인수가 `YEAR`, `MONTH` 또는 `DAY` 값의 일부 조합만 포함하는 간격이면 결정된 타입은 [`DATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)이고, 그렇지 않으면 해당 타입은 [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)입니다.
  - 첫 번째 인수가 [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)으로 결정되면, 함수의 결정된 타입도 `DATETIME`입니다.
  - 첫 번째 인수가 `DATE`이면, 간격 인수가 `HOUR`, `MINUTE` 또는 `SECOND`를 사용하지 않는 한 함수의 결정된 타입도 [`DATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)이며, 이 경우에는 [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)입니다.
  - 첫 번째 인수가 [`TIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/time.html) 값이면, 간격 인수가 `YEAR`, `MONTH` 또는 `DAY` 중 하나를 사용하지 않는 한 결정된 타입도 `TIME`이며, 이 경우 함수의 결정된 타입은 [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html)입니다.

  앞의 조건 중 어느 것도 충족되지 않으면, 함수는 (MySQL 8.0.21 및 이전 버전에서와 같이) [`VARCHAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/char.html)로 결정됩니다.

  `ADDTIME()` 및 [`SUBTIME()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_subtime) 함수는 이제 다음과 같이 타입을 결정합니다:

  - 첫 번째 인수가 동적 파라미터인 경우, 결정된 타입은 `DATETIME`이 아니라 `TIME`입니다.
  - 그렇지 않으면, 함수의 결정된 타입은 첫 번째 인수의 결정된 타입에서 파생됩니다.

  또한 `DATE_ADD()` 및 `DATE_SUB()`의 경우, 첫 번째 인수의 결정된 타입이 `DATE`이고 `DATETIME` 값이 제공되면, 함수가 결정된 타입 `DATETIME`을 갖도록 명령문이 다시 준비됩니다. `TIME` 값이 제공되는 경우 동작은 변경되지 않습니다.

  `ADDTIME()` 및 `SUBTIME()`의 경우, 강제 재준비는 없습니다. (Bug #103781, Bug #32915973, Bug #33477883, Bug #33539844)

- 이전에는 로드 가능한 함수와 저장 함수가 같은 네임스페이스를 공유했으며 같은 이름을 가질 수 없었습니다. 이후 구현 변경으로 같은 네임스페이스를 공유해야 하는 이유가 제거되었고, 기존 로드 가능한 함수와 같은 이름으로 저장 함수를 생성할 수 있게 되었습니다. 저장 함수를 호출하려면 스키마 이름으로 한정해야 합니다. 이제 저장 함수 이름이 기존 로드 가능한 함수 이름과 충돌하면 서버가 경고를 생성합니다. (Bug #33301931)
- [`MBRContains()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/spatial-relation-functions-mbr.html#function_mbrcontains) 함수를 사용하는 쿼리가 사용 가능한 모든 공간 인덱스를 활용하지 않았습니다. (Bug #32975221)

  References: 이 문제는 다음 버그의 회귀입니다: Bug #29770705.
- [`FORMAT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_format) 함수는 es_ES 또는 es_MX 로캘이 지정된 경우 천 단위 구분 기호와 구분 기호 사이의 그룹화를 표시하지 않고 형식화된 숫자를 반환했습니다. (Bug #31374305)
- [`GROUP_CONCAT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_group-concat) 함수의 결과 길이는 [`group_concat_max_len`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_group_concat_max_len) 값이 증가했을 때 잘못되었습니다. 작은 [`group_concat_max_len`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_group_concat_max_len) 값에서는 결과가 올바랐습니다. 이 문제는 산술 오버플로로 인해 발생했습니다.

  기여해 주신 Hope Lee에게 감사드립니다. (Bug #105380, Bug #33521497)

## Optimizer 관련 사항

- 쿼리의 경우 범위 스캔이 먼저 선택될 수 있으며, optimizer가 동일한 범위 스캔을 사용하여 정렬을 건너뛸 수 있다고 결정할 수 있습니다. 일부 경우에는 요청된 순서가 인덱스 순서와 같지 않을 때 역방향 인덱스 스캔이 필요합니다. 요청된 정렬이 범위 스캔에서 아직 사용되지 않은 키 부분에 대한 것인 경우, 변경 사항을 반영하도록 범위 스캔에 사용된 키 부분 수를 업데이트합니다. 이 문제는 키 부분 정보도 함께 업데이트되지 않았고, 사용된 키 부분 수를 기준으로 키 부분 정보에 액세스해야 할 때 발생했습니다.

  또한 이제 역방향 스캔이 확장된 키 부분을 사용할 때 이를 기록하고, 그에 따라 평가를 위한 올바른 플래그를 설정합니다. (Bug #33615893)

  참조: 이 문제는 다음의 회귀입니다: Bug #33037007.
- optimizer trace와 [`EXPLAIN FORMAT=TREE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-execution-plan) 출력 모두에서 날짜 범위가 바이너리로 출력되었습니다. 이제 이러한 경우 시간 값은 따옴표로 묶인 문자열로 출력됩니다. (Bug #33335079)
- 조건이 push down되었을 때, 서브쿼리의 `SELECT` 목록에서 사용자 변수에 대한 할당을 평가한 결과가 때때로 영향을 받았습니다. 이러한 이유로 이제 사용자 변수에 대한 할당이 있는 명령문에서는 조건 pushdown을 방지합니다.

  기여해 주신 Casa Zhang 및 Tencent 팀에 감사드립니다. (Bug #104918, Bug #33341080)
- 조인 버퍼가 특정 임의 크기로 설정되었을 때, 해시 조인을 위해 생성된 청크 파일 수가 너무 적었습니다. 이는 각 파일에 조인 버퍼에 들어갈 수 있는 것보다 더 많은 로우가 포함되어 probe 청크를 여러 번 읽어야 했음을 의미했습니다. 이는 필요한 청크 파일 수를 계산할 때 정수 나눗셈을 사용했기 때문에 발생했으며, 대신 부동소수점 나눗셈을 사용하여 이 문제를 수정했습니다.

  기여해 주신 Øystein Grøvlen에게 감사드립니다. (Bug #104186, Bug #33073354)
- [`BIT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/bit-type.html) 타입에 대해 집계를 사용하는 쿼리는 사용된 인덱스 또는 조인 타입에 따라 서로 다른 결과를 반환할 수 있었습니다. 이는 이러한 집계를 사용하는 DML 문이 정수 타입을 사용하여 `BIT` 값을 캐시한 다음, 나중에 출력을 위해 문자열 형식을 조회하고 변환한다는 사실 때문이었습니다. 현재 문제는 이 조회가 `BIT` 값을 정수로 처리하여 잘못된 문자열 값을 초래했기 때문에 발생했습니다.

  비트 값을 문자열 형식으로 올바르게 변환할 수 있는 캐시된 `BIT` 값을 위한 새로운 내부 클래스를 추가하여 이 문제가 수정되었습니다.

  기여해 주신 Hope Lee에게 감사드립니다. (Bug #100859, Bug #31894023)
- `HAVING` 절 내부에 서브쿼리가 있는 외부 `DISTINCT` 쿼리를 포함하는 DML 문에서, 내부 서브쿼리는 외부 `DISTINCT` 쿼리의 컬럼에 대한 컬럼 참조를 사용하려고 시도하지만, 이는 서브쿼리가 `HAVING` 외부의 어딘가에서 사용되거나 외부 `SELECT`가 그룹화를 사용하지 않는 경우에만 허용되어야 합니다. 현재 문제는 이러한 쿼리가 두 조건 중 어느 것도 충족하지 않았음에도 실행되도록 허용되었기 때문에 발생했습니다.

  이를 수정하기 위해, 컬럼 참조 검사가 이러한 종류의 유효하지 않은 컬럼 참조를 감지하고, 감지되는 경우 오류를 반환하도록 확장되었습니다.

  기여해 주신 Song Zhibai에게 감사드립니다. (Bug #97742, Bug #30617496)

## 패키징 관련 사항

- MySQL 다운로드 가능 패키지에 서명하는 데 사용되는 GnuPG 빌드 키가 업데이트되었습니다. 이전 GnuPG 빌드 키는 2022-02-16에 만료되도록 설정되어 있습니다. GnuPG 서명 확인을 사용하여 MySQL 다운로드 가능 패키지의 무결성과 진위를 확인하는 방법에 대한 정보 또는 공개 GnuPG 빌드 키 사본을 얻는 방법은 [Signature Checking Using GnuPG](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/checking-gpg-signature.html)를 참조하십시오.

  GnuPG 키 업데이트로 인해 `repo.mysql.com`을 사용하도록 설정된 시스템은 `apt` 또는 `yum`을 사용하여 MySQL 5.7.37 이상 또는 MySQL 8.0.28 이상으로 업그레이드할 때 서명 확인 오류를 보고할 수 있습니다. 이 문제를 해결하려면 다음 방법 중 하나를 사용하십시오:

  - [https://dev.mysql.com/downloads/](https://dev.mysql.com/downloads/)에서 MySQL APT 또는 YUM 저장소 설정 패키지를 수동으로 다시 설치하십시오.
  - MySQL GnuPG 공개 키를 다운로드하고 시스템 GPG 키링에 추가하십시오.

    - MySQL APT 저장소 지침은 [Appendix A: Adding and Configuring the MySQL APT Repository Manually](https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/#repo-qg-apt-repo-manual-setup)를 참조하십시오.
    - MySQL YUM 저장소 지침은 [Upgrading MySQL with the MySQL Yum Repository](https://dev.mysql.com/doc/mysql-yum-repo-quick-guide/en/#repo-qg-yum-upgrading)을 참조하십시오.

  (Bug #33587308)

- 번들로 제공되는 `libedit` 라이브러리가 버전 20210910-3.1로 업그레이드되었습니다. (Bug #33568767)

## Performance Schema 관련 사항

- 새로운 문장 메트릭인 `CPU_TIME`을 이제 사용할 수 있으며, 이를 통해 쿼리에 소요된 CPU 시간을 측정할 수 있습니다.

  이를 지원하기 위해 다음 변경 사항이 적용되었습니다:

  - 타이머 `THREAD_CPU`가 Performance Schema [`PERFORMANCE_TIMERS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-performance-timers-table.html) 테이블에 추가되었습니다.
  - 컨슈머 `events_statements_cpu`가 Performance Schema [`setup_consumers`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-setup-consumers-table.html) 테이블에 추가되었습니다.

    `events_statements_cpu`는 기본적으로 비활성화되어 있습니다.
  - 컨슈머 `events_statements_cpu`를 활성화하거나 비활성화하기 위한 Performance Schema 명령 옵션 `performance-schema-consumer-events-statements-cpu`.

    자세한 내용은 [Performance Schema Command Options](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-options.html)를 참조하십시오.
  - 다음 컬럼이 추가되었습니다:

    - `CPU_TIME` 컬럼이 다음 Performance Schema 테이블에 추가되었습니다:

      - [`events_statements_current`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-current-table.html)
      - [`events_statements_history`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-history-table.html)
      - [`events_statements_history_long`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-history-long-table.html)

      `CPU_TIME`은 현재 스레드에 대해 CPU에서 소요된 시간이며, 피코초 단위로 표현됩니다.
    - `SUM_CPU_TIME` 컬럼이 다음 Performance Schema 테이블에 추가되었습니다:

      - [`events_statements_summary_by_thread_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_by_account_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_by_user_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_by_host_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_global_by_event_name`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_by_digest`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`events_statements_summary_by_program`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html)
      - [`prepared_statements_instances`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-prepared-statements-instances-table.html)

        SUM_CPU_TIME은 해당 집계에 대해 현재 스레드에서 사용된 CPU 시간이며, 피코초 단위로 표현됩니다.
    - `CPU_LATENCY` 컬럼이 다음 sys 스키마 테이블에 추가되었습니다:

      - [`statement_analysis`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-statement-analysis.html)
      - [`user_summary_by_statement_type`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-user-summary-by-statement-type.html)
      - [`user_summary_by_statement_latency`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-user-summary-by-statement-latency.html)
      - [`host_summary_by_statement_type`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-host-summary-by-statement-type.html)
      - [`host_summary_by_statement_latency`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-host-summary-by-statement-latency.html)
      - [`processlist`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-processlist.html)
      - [`session`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-session.html)

      CPU 지연 시간은 현재 스레드에서 사용된 CPU 시간이며, 사람이 읽을 수 있는 형식으로 표현됩니다.
    - `CPU_LATENCY` 컬럼이 다음 sys 스키마 `x$` 테이블에 추가되었습니다:

      - [`x$statement_analysis`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-statement-analysis.html)
      - [`x$user_summary_by_statement_type`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-user-summary-by-statement-type.html)
      - [`x$host_summary_by_statement_type`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-host-summary-by-statement-type.html)
      - [`x$processlist`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-processlist.html)
      - [`x$session`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-session.html)
      - [`x$user_summary_by_statement_latency`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-user-summary-by-statement-latency.html)
      - [`x$host_summary_by_statement_latency`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-host-summary-by-statement-latency.html)

      CPU 지연 시간은 현재 스레드에서 사용된 CPU 시간이며, 피코초 단위로 표현됩니다.

  이 수정에 기여해 주신 Facebook에 감사드립니다. (Bug #32202060, Bug #101764, WL #14779)

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

- **중요한 변경 사항:** 지정된 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)에 나타날 수 있는 고유 윈도우의 수는 이제 127개로 제한됩니다. 고유 윈도우의 수는 명명된 윈도우와 임의의 윈도우 함수 `OVER` 절의 일부로 지정된 암시적 윈도우의 합입니다.

  많은 수의 윈도우를 사용하려면 [`thread_stack`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_thread_stack) 서버 시스템 변수의 값을 늘려야 할 수 있습니다. (Bug #33279604)
- **InnoDB:** `InnoDB`는 이제 `ALGORITHM=INSTANT`를 사용하는 [`ALTER TABLE... RENAME COLUMN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 작업을 지원합니다.

  `ALGORITHM=INSTANT`를 지원하는 작업은 데이터 딕셔너리의 메타데이터만 수정합니다. 테이블 데이터는 영향을 받지 않으므로 작업이 즉시 수행됩니다. 명시적으로 지정하지 않으면, 이를 지원하는 DDL 작업에서 기본적으로 `ALGORITHM=INSTANT`가 사용됩니다.

  `ALGORITHM=INSTANT`를 지원하는 이 DDL 작업과 다른 DDL 작업에 대한 자세한 내용은 [Online DDL Operations](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-online-ddl-operations.html)를 참조하십시오. (WL #14785)
- MySQL Enterprise Audit을 사용하는 충분한 권한을 가진 사용자가 감사 로그 필터에 “abort” 항목을 실수로 생성하여 자신과 다른 관리자가 시스템에 액세스하지 못하게 할 이론적 가능성이 있습니다. MySQL 8.0.28부터는 “abort” 항목이 쿼리를 차단할 수 있는 경우에도 사용자 계정의 쿼리가 항상 실행되도록 허용하는 `AUDIT_ABORT_EXEMPT` 권한을 사용할 수 있습니다. 따라서 이 권한이 있는 계정은 감사 설정 오류 이후 시스템에 대한 액세스를 복구하는 데 사용할 수 있습니다. 쿼리는 여전히 감사 로그에 기록되지만, 거부되는 대신 이 권한으로 인해 허용됩니다.

  MySQL 8.0.28 이상에서 `SYSTEM_USER` 권한으로 생성된 계정에는 생성 시 `AUDIT_ABORT_EXEMPT` 권한이 자동으로 할당됩니다. MySQL 8.0.28 이상으로 업그레이드 절차를 수행할 때 기존 계정에 해당 권한이 할당되어 있지 않으면, `AUDIT_ABORT_EXEMPT` 권한은 `SYSTEM_USER` 권한이 있는 기존 계정에도 할당됩니다. (WL #14670)

- [`tmp_table_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_tmp_table_size) 변수는 이제 TempTable 스토리지 엔진이 생성하는 개별 인메모리 내부 임시 테이블의 최대 크기를 정의합니다. 적절한 크기 제한은 개별 쿼리가 과도한 양의 전역 TempTable 리소스를 소비하지 않도록 방지합니다. [Internal Temporary Table Storage Engine](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/internal-temporary-tables.html#internal-temporary-tables-engines)을 참조하십시오. (WL #14647)
- 한 번에 열어 둘 수 있는 `InnoDB` 파일 수를 정의하는 [`innodb_open_files`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_open_files) 변수는 이제 `SELECT innodb_set_open_files_limit(N)` 문을 사용하여 런타임에 설정할 수 있습니다. 이 문은 새 제한을 설정하는 저장 프로시저를 실행합니다.

  non-LRU 관리 파일이 전체 [`innodb_open_files`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_open_files) 제한을 소비하지 않도록, non-LRU 관리 파일은 이제 [`innodb_open_files`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_open_files) 제한의 90퍼센트로 제한되며, 이는 LRU 관리 파일을 위해 [`innodb_open_files`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_open_files) 제한의 10퍼센트를 예약합니다.

  [`innodb_open_files`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_open_files) 제한에는 이제 이전에는 제한에 계산되지 않았던 임시 테이블스페이스 파일이 포함됩니다. (WL #14591)
- [`FROM_UNIXTIME()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_from-unixtime), [`UNIX_TIMESTAMP()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_unix-timestamp), [`CONVERT_TZ()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_convert-tz) 함수는 이제 64비트 버전의 Linux, MacOS, Windows를 포함하여 이를 지원하는 플랫폼에서 64비트 값을 처리합니다.

  호환되는 플랫폼에서 `FROM_UNIXTIME()`은 이제 최대 인수로 32536771199.999999초를 허용하며, 이는 UTC `'3001-01-18 23:59:59.999999'`에 해당합니다(최대 6자리의 선택적 소수부 포함). 인수가 이보다 크면 함수는 `NULL`을 반환합니다.

  source? I’ll maintain “이 3개 함수” and ensure I'm considering future dates. No notes
 need to be added in the final version.**Finalizing translation details**

  호환되는 플랫폼에서 `UNIX_TIMESTAMP()`는 이제 Unix Epoch 이후 32536771199.999999초에 해당하는 UTC `'3001-01-18 23:59:59.999999'`의 최대값을 허용합니다. 인수가 이보다 크면 이 함수는 `0`을 반환합니다.

  또한 호환되는 플랫폼에서 `CONVERT_TZ()`는 이제 2038년 이후, UTC `'3001-01-18 23:59:59.999999'`까지 시간대 변환을 수행합니다. datetime 인수가 이 값을 초과하면 인수는 변경되지 않은 상태로 반환됩니다. 이 “no-op” 동작은 이전에 UTC `'2038-01-19 03:14:07.999999'`를 초과하는 값에서와 동일합니다.

  32비트 플랫폼에서 이 3개 함수의 동작은 변경되지 않았습니다.

  [`TIMESTAMP`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 타입의 동작도 이 변경의 영향을 받지 않습니다. 허용되는 최대값은 플랫폼과 관계없이 UTC `'2038-01-19 03:14:07.999999'`로 유지됩니다. 이보다 미래의 날짜에는 대신 MySQL [`DATETIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/datetime.html) 타입을 사용하십시오. (WL #14630)
- 이 릴리스는 전역 및 사용자별 기준으로 메모리 할당 모니터링 및 제한을 도입합니다. 이제 [`global_connection_memory_tracking = 1`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_global_connection_memory_tracking)을 설정하여 활성화해야 하는 [`Global_connection_memory`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Global_connection_memory) 상태 변수의 값을 확인하여 모든 사용자 연결이 소비한 전체 메모리를 관찰할 수 있습니다.

  이 전체에는 시스템 프로세스 또는 MySQL root 사용자가 사용하는 메모리가 포함되지만, 이러한 사용자는 메모리 사용량으로 인해 연결 해제 대상이 되지 않습니다.

  [`InnoDB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-storage-engine.html) 버퍼 풀에서 사용하는 메모리는 전체에 포함되지 않습니다.

  [`connection_memory_chunk_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_connection_memory_chunk_size)를 조정하여 상태 변수가 업데이트되는 빈도를 간접적으로 제어할 수 있습니다. `Global_connection_memory`는 전체 메모리 사용량이 이 양보다 많이 달라지는 경우에만 업데이트됩니다.

  [`connection_memory_limit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_connection_memory_limit)를 설정하여 사용자 연결별 리소스 소비 제한을 지정할 수 있습니다. 메모리 사용량이 이 양을 초과하는 사용자는 추가 쿼리를 실행할 수 없습니다. 또한 [`global_connection_memory_limit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_global_connection_memory_limit)를 설정하여 전역 메모리 제한을 적용할 수 있습니다. `Global_connection_memory`가 전역 제한을 초과할 때마다 일반 사용자는 메모리 사용량이 필요한 새 쿼리를 실행할 수 없습니다. MySQL root와 같은 시스템 사용자는 이러한 제한의 적용을 받지 않습니다. (WL #13458)

## 수정된 버그

- **InnoDB:** 인덱스 생성 작업 중 계산된 최소 I/O 버퍼 크기가 I/O 블록 크기와 정렬되지 않아, 레코드가 버퍼 경계를 초과할 수 있었습니다. (Bug #33570629)
- **InnoDB:** 디버그 빌드에서 세마포어 데드락 검사기가 사용하는 `sync_array_detect_deadlock` 알고리즘이 코드 및 시간 복잡도 측면에서 단순화되었으며, 릴리스 빌드에서 사용할 알고리즘 구현이 도입되었습니다. (Bug #33538505)
- **InnoDB:** 이제 `InnoDB` 소스의 `ut::make_unique` 라이브러리 함수에서 할당되는 필드의 타입을 지정할 수 있습니다. (Bug #33538461)
- **InnoDB:** redo 로그 버퍼 메모리 할당을 추적하기 위한 Performance Schema 계측이 추가되었습니다. (Bug #33527660)
- **InnoDB:** 긴 세마포어 대기에 대해 오류 로그에 출력되는 경고가 래치 소유자에 대한 정보를 제공하지 않았습니다. (Bug #33509386)
- **InnoDB:** 전역 잠금 시스템 래치로 보호되는 중요 섹션에서 스레드가 소요하는 시간을 줄이기 위해 래치 해제 및 재획득 메커니즘이 도입되었습니다. (Bug #33502610, Bug #33563523)
- **InnoDB:** Windows에서 hole punch 작업으로 인해 실패가 발생했습니다. 이 작업은 overlapped(비동기) 작업으로 수행되었으며, 이벤트 객체에 대한 핸들을 포함하는 `OVERLAPPED` 구조체가 필요합니다. `OVERLAPPED` 구조체가 제공되지 않았습니다. (Bug #33496778)

- **InnoDB:** `InnoDB` 소스의 `ut_time()` 인프라가 타입 검사되는 표준 라이브러리 구현으로 대체되었습니다. (Bug #33460092)
- **InnoDB:** 복원 작업 후 다수의 Trying to access missing tablespace 오류가 오류 로그에 출력되었습니다. (Bug #33437625)
- **InnoDB:** Performance Schema를 인식하는 `ut::make_unique` 및 `ut::make_shared` 메모리 관리 라이브러리 함수가 `InnoDB` 소스에 추가되었습니다. 확장 정렬이 있는 타입을 위해 유사한 함수(`ut::make_unique_aligned` 및 `ut::make_shared_aligned`)가 추가되었습니다. (Bug #33420694)
- **InnoDB:** `InnoDB` 소스의 `buf_validate()` 함수가 최적화되어 디버그 빌드에서 성능이 향상되었습니다.

  기여해 주신 Hobert Lu에게 감사드립니다. (Bug #33417058, Bug #104967)
- **InnoDB:** NUMA가 활성화된 시스템에서, 특정 시나리오에서 버퍼 풀에 할당된 메모리 청크의 페이지 크기가 시스템 페이지 크기와 정렬되지 않아 다음 오류가 발생했습니다: Failed to set NUMA memory policy of buffer pool page frames to MPOL_INTERLEAVE. (Bug #33406701)

  참조: 이 문제는 다음의 회귀입니다: Bug #32714144.
- **InnoDB:** `InnoDB` 소스에서 `mem_heap`이 있는 `std::unique_ptr`의 두 인스턴스는 이제 `Scoped_heap()` 래퍼를 사용하며, 이 래퍼는 함수에 대한 포인터 대신 상태 없는 함수 객체를 사용합니다. (Bug #33405520)

- **InnoDB:** 프리페치 캐시를 채우는 동안 범위의 끝을 초과하면 true로 설정되는 `prebuilt` 구조체의 `m_end_range` 플래그가 프리페치 캐시가 재설정(초기화)될 때 false로 설정되지 않았습니다. 그 결과, 범위의 끝을 초과하지 않고 핸들러가 재사용되는 경우, 다음에 프리페치 캐시가 사용될 때 `m_end_range` 플래그가 잘못 설정될 수 있었습니다. (Bug #33384537)
- **InnoDB:** 테이블 import 작업 중 테이블의 테이블스페이스를 폐기한 후 테이블에 새 테이블 ID가 할당될 때 데이터 딕셔너리의 컬럼 메타데이터가 업데이트되지 않았습니다. (Bug #33319149)
- **InnoDB:** 디버그 전용 시스템 변수 `innodb_interpreter`를 `NULL`로 설정하면 실패가 발생했습니다. (Bug #33316661)
- **InnoDB:** Full-text 인덱스 생성 파일 관리가 개선되었습니다. (Bug #33270893)
- **InnoDB:** 집계에 사용되는 임시 테이블에 새 로우를 삽입한 update 작업으로 인해 임시 테이블이 디스크로 이동되고, 새 디스크 기반 임시 테이블에서 update 작업이 재시도되었습니다. 임시 테이블이 디스크로 이동되기 전에 준비된 레코드 데이터의 BLOB 포인터가 오래된 상태가 되어 실패가 발생했습니다. (Bug #33242407)
- **InnoDB:** 이제 메모리 할당은 Performance Schema와 호환되는 새로운 표준 준수 커스텀 메모리 allocator에 의해 수행됩니다. (Bug #33159210)

- **InnoDB:** 동일한 테이블에 대해 통계를 해제하고 초기화하려고 시도하는 스레드 간의 경쟁 조건으로 인해 어설션 실패가 발생했습니다. (Bug #33135425)
- **InnoDB:** [`innodb_flush_log_at_trx_commit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit) 설정이 1이 아니거나 장기 실행 트랜잭션이 있는 경우, redo log 플러시 비율이 일관되지 않을 수 있었습니다. (Bug #33128461)
- **InnoDB:** 이제 large page 할당은 이를 처리하도록 설계된 라이브러리에서 처리됩니다. large page 할당 메커니즘을 사용할 수 없는 경우, fallback 메커니즘이 일반 정렬 페이지를 할당합니다. fallback은 large page 주소 공간이 고갈된 경우, 기반 하드웨어 또는 운영체제 아키텍처에서 large page 지원이 비활성화된 경우, 또는 MySQL에서 large page 지원이 명시적으로 비활성화된 경우([`--large-pages=0`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-options.html#option_mysqld_large-pages)) 발생할 수 있습니다. large page의 할당 및 할당 해제를 위한 `ut_allocator` 함수 사용 부분은 새 라이브러리 함수로 대체되었습니다. (Bug #33119009, Bug #33118309, Bug #33149501, Bug #32135935)
- **InnoDB:** 일반 4K page-aligned 할당 처리는 이제 Performance Schema와 호환되는 자체 완결형 라이브러리에서 수행됩니다. (Bug #33118362)

- **InnoDB:** 적절히 정렬된 타입의 동적 스토리지 관리를 담당하는 새로운 `InnoDB` 라이브러리에 속한 함수가, 이전에 이 목적으로 사용되던 함수를 대체했습니다. (Bug #33110341)
- **InnoDB:** 적절히 정렬된 타입의 동적 할당은 이제 Performance Schema와 호환되는 라이브러리에서 처리됩니다. (Bug #33110312)
- **InnoDB:** 퍼지 스레드가 퍼지 배치 끝에서 LOB 페이지를 해제하는 동안, 필요한 인덱스 데이터 구조가 해제되어 실패가 발생했습니다. (Bug #32918325)
- **InnoDB:** 동적 메모리 관리 함수(`ut_*` 함수)에 대한 Performance Schema 계측 로직의 불일치가 해결되었습니다. (Bug #32715466)
- **InnoDB:** `InnoDB` 동적 할당 루틴의 제한으로 인해 생성 가능한 타입의 배열을 동적으로 할당할 수 없었습니다. 이 제한이 해결되어, 기본 생성 가능한 타입, 기본 생성 가능하지 않은 타입, 그리고 기본 생성 가능하면서 동시에 기본 생성 가능하지 않은 타입의 할당이 허용됩니다. (Bug #32714047)

- **InnoDB:** [`READ COMMITTED`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-transaction-isolation-levels.html#isolevel_read-committed) 또는 [`READ UNCOMMITTED`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-transaction-isolation-levels.html#isolevel_read-uncommitted)를 사용할 때, 트리거 또는 함수 내부의 테이블에서 실행된 특정 쿼리가 같은 테이블의 동시 트랜잭션을 방해했습니다. 획득된 잠금이 너무 제한적이었습니다. (Bug #32636792)
- **InnoDB:** hole punch 기능이 암호화 및 압축된 테이블스페이스 페이지, Windows의 대부분 페이지, 그리고 Microsoft 볼륨 관리 함수를 구현하지 않는 Windows 볼륨에 대해 예상대로 작동하지 않았습니다. (Bug #32136255)
- **InnoDB:** MySQL 8.0.28에서 `ut_time()` 인프라를 타입 검사가 적용된 표준 라이브러리(`std`) 구현으로 대체하면서 성능 회귀가 발생했습니다. 이 회귀는 시스템 호출을 생성하는 `std` 클록에서 사용하는 시간 라이브러리 때문이었습니다. 이제 대신 저해상도 클록이 사용됩니다. (Bug #107763, Bug #34352870)

  References: 이 문제는 다음의 회귀입니다: Bug #33460092.
- **Packaging:** `server` 패키지에서 분리된 `icu-data-files` RPM이 추가되었습니다. 이는 MySQL 정규 표현식에 필요한 ICU 데이터 파일 패키지입니다. (Bug #35162346)

- **파티셔닝:** 생성 컬럼 표현식에 비결정적 함수를 사용하여 테이블을 생성하는 것은 가능해서는 안 되지만, 모든 경우에 이것이 강제되지는 않았습니다. 하나 이상의 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문을 연속으로 사용하여 그러한 생성 컬럼을 하나 이상 포함하는 파티션된 테이블에 도달할 수 있었습니다. 이 테이블에 대해 [`SHOW CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-create-table.html)을 실행하여 얻은 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html) 문을 실행하려고 하면, 파티셔닝 표현식 자체는 유효했음에도 MySQL은 문제가 있는 컬럼이 아니라 파티셔닝 표현식을 참조하는 잘못된 오류 메시지와 함께 해당 문을 거부했습니다.

  이는 생성 컬럼에 정의된 안전하지 않은 표현식이 있는지 검사한 결과(내부 변수 `thd->safe_to_cache_query`)가 원인이었으며, 이 값은 나중에 파티션 표현식을 파싱하는 동안 지워지지 않은 채 다시 검사되어, 파티션 표현식이 문제가 있는 생성 컬럼 표현식을 참조하지 않는 경우에도 오류가 발생했습니다. 이제 이러한 경우에는 파티션 함수를 파싱하기 전에 `thd->safe_to_cache_query`를 재설정합니다.

  생성 컬럼에서 특정 비결정적 함수([`AES_ENCRYPT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/encryption-functions.html#function_aes-encrypt), [`AES_DECRYPT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/encryption-functions.html#function_aes-decrypt), [`RANDOM_BYTES()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/encryption-functions.html#function_random-bytes))의 사용을 허용하는 문제는 별도로 처리됩니다. (Bug #29268656)

  참고: 다음도 참조하십시오: Bug #32592320.
- **파티셔닝:** 파티셔닝된 테이블의 기본 키가 아닌 인덱스를 사용하는 쿼리가 때때로 과도한 CPU 부하를 초래했습니다. (Bug #104576, Bug #33238010)
- **Replication:** 인스턴스가 백업을 위해 잠겨 있는 동안 `PURGE BINARY LOGS` 문을 실행할 수 있었으며, 이는 서버에서 파일을 제거함으로써 백업 잠금의 규칙을 위반했습니다. 이제 LOCK INSTANCE FOR BACKUP 문이 적용 중인 동안에는 이 문을 사용할 수 없습니다. (Bug #33437026)
- **Replication:** 테이블 또는 데이터베이스 이름이 64바이트를 초과하는 경우 테이블 맵 이벤트를 읽을 때 복제가 오류와 함께 중지되었습니다. 제한은 64자이므로 멀티바이트 문자를 사용하면 이 상황이 발생할 수 있었습니다. 이제 복제본은 테이블 및 데이터베이스 이름의 크기를 더 이상 검사하지 않으며, 더 긴 이름의 전송을 지원합니다. (Bug #33305975, Bug #104798)
- **Replication:** `STOP REPLICA` 명령이 진행 중일 때 Performance Schema 테이블 `replication_applier_status_by_worker`를 쿼리하면 잠금 충돌이 발생할 수 있었습니다. 이 문제는 이제 해결되었습니다. (Bug #33290947)

- **Replication:** MySQL 8.0.26부터 반동기 복제를 구현하는 플러그인의 새 버전이 “master” 및 “slave” 용어를 “source” 및 “replica”로 대체하기 위해 제공되었습니다. 이에 따라 `UNINSTALL PLUGIN` 문이 복제 채널에서 현재 사용 중인 플러그인의 이전 버전인 `rpl_semi_sync_master` 및 `rpl_semi_sync_slave`를 잘못 제거할 수 있었습니다. 이 문제는 이제 수정되었습니다. (Bug #33270401)
- **Replication:** 복제본 서버에서 `PAD_CHAR_TO_FULL_LENGTH` SQL 모드가 활성화된 경우, 복제 메타데이터 저장소 테이블의 복제 채널 이름에 후행 공백이 추가될 수 있었으며, 이로 인해 해당 데이터를 사용하여 채널을 식별하는 복제 작업에서 오류가 발생했습니다. 이 문제는 MySQL 8.0에서는 캐릭터 컬럼에 VARCHAR를 사용하고, MySQL 5.7에서는 해당 테이블에서 읽을 때 SQL 모드를 비활성화하여 이제 수정되었습니다. 기여해 주신 Brian Yue에게 감사드립니다. (Bug #33213841)
- **Replication:** `SHOW REPLICAS` 문이 실행되는 동안 복제본의 연결이 끊어지고 있던 경우, 서버가 삭제된 데이터에 접근할 수 있었습니다. (Bug #33206343, Bug #104566)

- **Replication:** 시스템 변수 `replica_preserve_commit_order = 1`이 설정된 복제 서버가 장기간 집중적인 부하에서 사용된 경우, 인스턴스의 커밋 순서 시퀀스 티켓이 고갈될 수 있었습니다. 최댓값을 초과한 후의 잘못된 동작으로 인해 어플라이어가 중단되고 어플라이어 작업자 스레드가 커밋 순서 큐에서 무기한 대기했습니다. 이제 커밋 순서 시퀀스 티켓 생성기가 올바르게 래핑됩니다. 기여해 주신 Zhai Weixiang에게 감사드립니다. (Bug #32891221, Bug #103636)
- **Replication:** 복제 소스 서버가 바이너리 로그 파일의 큰 크기로 인해 4GB 오프셋을 초과하는 바이너리 로그 파일 위치를 포함하는 하트비트 이벤트를 보낸 경우, 복제 리시버 스레드가 오류와 함께 중지되었습니다. 이 상황에서 사용하기 위해 더 큰 값을 올바르게 처리하는 새 하트비트 이벤트(Heartbeat_log_event_v2, 로그 이벤트 타입 41)가 추가되었습니다. (Bug #29913991)
- **Group Replication:** Performance Schema 복제 그룹 멤버 통계 테이블이 검사되는 동안 자동 재참여 절차 중에 Group Replication이 예기치 않게 중지될 수 있었습니다. 이제 작업의 동시성이 올바르게 처리됩니다. (Bug #33609089)

- **Group Replication:** 그룹 멤버를 분산 복구의 기증자로 선택하는 Group Replication의 선택 프로세스에는 운영 체제에 대해 정의된 표준 랜덤 선택기의 사용이 포함됩니다. 이 랜덤 장치를 사용할 수 없고 예외가 발생하면 멤버의 조인 프로세스가 중지되었습니다. 이제 Group Replication은 이 가능성을 고려하며, 운영 체제의 랜덤 선택기가 오류를 반환하는 경우 대체 랜덤 선택기를 사용합니다. (Bug #33596124)
- **Group Replication:** `STOP GROUP_REPLICATION` 문은 그룹 멤버의 비동기 복제 채널을 중지하지만, `STOP REPLICA`처럼 해당 채널에서 진행 중인 트랜잭션을 암시적으로 커밋하지 않습니다. 이는 Group Replication 그룹 멤버에서 종료 작업 중에 추가 트랜잭션이 커밋되면 멤버가 그룹과 불일치하게 되고 재조인에 문제가 발생하기 때문입니다. 작업이 완료된 후 서버는 읽기 전용 상태로 남습니다. 이 상황은 Group Replication을 중지하는 동안 진행 중인 트랜잭션의 커밋 실패로 이어지므로, 이를 방지하기 위해 이제 `gtid_next` 시스템 변수의 값으로 GTID가 할당되어 있는 동안에는 `STOP_GROUP_REPLICATION` 문을 실행할 수 없습니다. (Bug #33412483)

- **Group Replication:** Group Replication 자동 재참여 절차를 사용하는 축출된 그룹 멤버가, 아직 다른 그룹 멤버에서 정보를 수집하고 있고 호환성 검사가 완료되기 전임에도 자신의 상태를 너무 이른 시점에 RECOVERING으로 보고했습니다. 이제 상태 변경은 뷰가 설치되는 동안 수행되며, 이 시점은 재참여하는 멤버가 실제로 그룹 멤버로 허용되는 지점입니다. (Bug #33380840)
- **Group Replication:** CMake 옵션 `DWITH_GROUP_REPLICATION=0`을 사용하여 MySQL 소스 배포판에서 Group Replication 플러그인을 비활성화해도 Group Replication과 관련된 애플리케이션 및 테스트가 비활성화되지 않았으며, 이로 인해 해당 항목들이 잘못 빌드되었습니다. (Bug #33308513)

- **Group Replication:** Group Replication에서 그룹 멤버에 `SET gtid_next` 문을 사용하여 다음 트랜잭션의 GTID를 설정하는 경우, 다른 멤버에서 동시에 시작되는 트랜잭션에 동일한 GTID가 사용될 수 있습니다. 두 트랜잭션이 모두 커밋 단계에 도달하면, 전체 순서에서 두 번째 트랜잭션이 롤백되어 이 상황이 해결됩니다. 그러나 Group Replication의 트랜잭션 일관성 수준(`group_replication_consistency` 시스템 변수)이 `BEFORE` 또는 `BEFORE_AND_AFTER`로 설정된 경우, 한 멤버는 `gtid_owned` 집합에서 GTID의 소유권을 보유하고 다른 멤버는 트랜잭션을 커밋하기 전에 소유권이 해제되기를 기다리면서 멤버들이 데드락에 도달할 수 있었습니다. 이제 대기 함수는 커밋된 트랜잭션의 GTID만 고려하고, 소유되었지만 커밋되지 않은 GTID는 고려하지 않습니다. 단, 세션이 동시에 커밋되는 GTID를 소유한 경우에는 예외이며, 이 경우 실행 중인 세션에서 오류가 발생합니다. (Bug #33051454, Bug #104096)
- **Group Replication:** 이제 Group Replication의 그룹 통신 엔진(XCom, Paxos 변형)은 예를 들어 네트워크 문제로 인해 기존 그룹 멤버가 참여하는 멤버와 통신하는 데 어려움을 겪는 상황에서 더 많은 정보를 로깅합니다. 이로 인해 그룹이 참여하는 멤버의 이전 인카네이션을 기억하고, 해당 멤버가 다시 참여를 시도하지 못하게 할 수 있습니다. (Bug #32873315)

- **Group Replication:** Group Replication의 Group Communication System (GCS)은 이제 축출된 멤버 기록에서 그룹에 성공적으로 참여했던 멤버와 그룹에 참여하지 못했던 멤버를 구분합니다. (Bug #32630484)
- **Group Replication:** Group Replication이 시작되거나 중지되는 중에 Performance Schema의 Group Replication 그룹 멤버 통계가 쿼리되면 경쟁 조건이 발생했습니다. (Bug #32392468)
- **Microsoft Windows:** Windows에서 MySQL Server (commercial) 및 MySQL NDB Cluster (commercial and community)에 대해 누락된 debug 및 테스트 스위트 바이너리를 추가했습니다. (Bug #32713189)
- **JSON:** [`JSON_TABLE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-table-functions.html#function_json-table)에 전달된 첫 번째 인수가 단일 JSON 값이 아니라 로우인 경우, 로우 표현식을 평가하려고 하는 동안 assertion이 발생했습니다. 첫 번째 인수가 로우이면 함수 해석 중 오류를 발생시켜 로우 표현식 자체가 평가되지 않도록 하여 이를 수정했습니다. (Bug #33414235)
- 생성된 컬럼의 표현식에서 [`LPAD()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_lpad) 또는 [`RPAD()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_rpad)를 사용하면 상위 테이블의 인덱스가 손상되었습니다. (Bug #33661337)

  참조: 함께 참조하십시오: Bug #32668730, Bug #33238711.

- 경고가 발생한 일부 경우에 임시 테이블을 사용하는 집계 결과에서 로우가 누락되었습니다. (Bug #33603911)
- openSUSE 15의 경우 이제 TI-RPC를 사용하도록 `mysql.spec`에 libtirpc rpcgen 빌드 요구 사항을 추가했습니다. (Bug #33582982)
- 여러 테이블에 작용하는 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html) 문이 실행될 때마다 목록에 요소를 추가하는 경우가 있었습니다. 요소가 이 목록에서 제거되지 않아, 문이 실행될 때마다 메모리 사용량이 증가했습니다. 실행 후 요소 목록을 지우도록 하여 이 문제를 수정했습니다. (Bug #33574408)
- Performance Schema [`processlist`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-processlist-table.html) 테이블의 `HOST` 컬럼 크기가 VARCHAR(255)에서 VARCHAR(261)로 증가했습니다. (Bug #33570218)
- OpenSSL 오류로 인한 keyring 마이그레이션 실패가 어설션을 발생시켰습니다. SSL 오류 상태가 스레드의 OpenSSL 오류 큐에서 플러시되지 않았습니다. (Bug #33546207)
- 프로세스 목록 함수 호출이 실패를 발생시켰습니다. (Bug #33511690)
- 상용 Debian 서버 패키지에는 두 개의 테스트 플러그인(component_test_page_track_component.so 및 component_test_global_priv_registration.so)이 포함되어 있었으며, 이 플러그인은 별도의 선택적 테스트 패키지로 이동되었습니다. (Bug #33504443)

- Fedora의 경우, 동일한 버전의 네이티브 Fedora dnf/yum 패키지와 관련된 잠재적인 설치 관련 문제를 제거하는 데 도움이 되도록 릴리스 패키지 버전 번호를 1에서 10으로 높였습니다. (Bug #33504443)
- Debian 기반 패키지의 compat 레벨을 11로 높였습니다. 이전 레벨인 9는 더 이상 사용되지 않기 때문입니다. 또한 호환성 레벨 10+의 요구 사항을 충족하도록 dh_systemd_enable + dh_systemd_start 호출을 dh_installsystemd로 대체했습니다. (Bug #33458752)
- Full-text search 쿼리를 포함하는 삭제 작업에서 실패가 발생했습니다. (Bug #33455243)
- 부적절하게 처리된 오류로 인해 `keyring_okv` 플러그인을 사용할 때 시작 실패가 발생했습니다. (Bug #33449117)
- Debian의 경우, debug 빌드에 필요한 모든 필수 패키지를 가져오도록 `mysql-community-server-debug` 패키지에 `mysql-community-server` 의존성을 추가했습니다. (Bug #33426737)
- [`DECIMAL`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/fixed-point-types.html) 타입의 가상 생성 컬럼에 대해, 필드 버퍼를 decimal 값으로 변환하려고 할 때 정의되지 않은 동작을 피할 수 있도록 이제 항상 일부 데이터를 저장합니다. (Bug #33424846)
- MySQL은 이제 기본 derived 테이블의 표현식에 저장 프로시저가 설정한 변수가 포함되어 있을 때 조건을 derived 테이블로 push down하는 것을 지원합니다. (Bug #33423394)

- [`tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_tls_version) 및 [`admin_tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_admin_tls_version) 설정은 이제 서버 시작 시 검증됩니다. (Bug #33390209)
- [`admin_tls_version`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_admin_tls_version) 변수는 잘못된 값을 허용했습니다. (Bug #33389818)
- 두 개 이상의 사용 중단된 시스템 변수가 `SET PERSIST` 문을 사용하여 유지된 경우, 서버가 재시작될 때 사용 중단 경고가 사용 중단된 시스템 변수 중 첫 번째 변수에 대해서만 기록되었습니다. (Bug #33388488)
- 키 파트가 같은 인덱스 범위 스캔의 경우, 이제 범위가 동등 조건으로 표시됩니다. 예를 들어, 이 변경 전의 `3 <= a <= 3` 대신 이제 `a = 3`이 표시됩니다. (Bug #33351123)
- `tmpfiles.d` 설정 파일에서 `/var/run` 사용이 [사용 중단](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html)되었으므로 `/var/run` 참조를 `/run`으로 대체했습니다. 현재 설정이 계속 작동하도록 `/var/run`에서 `/run`으로의 심볼릭 링크는 유지됩니다. (Bug #33351110, Bug #33588618)

- 특정 설정을 사용하는 서버에서 [`SHOW PROCESSLIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-processlist.html)를 실행하거나 [`INFORMATION_SCHEMA.PROCESSLIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-processlist-table.html)에 접근하면 실패가 발생했습니다. (Bug #33341623)
- ICU 오류 코드 `U_FILE_ACCESS_ERROR`에서 새 MySQL 오류 코드 [`ER_REGEXP_MISSING_FILE`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_regexp_missing_file)로의 매핑을 추가했습니다. (Bug #33326003)
- 실패한 keyring 함수 인수 검증 검사로 인해 실패가 발생했습니다. (Bug #33319782)
- 인덱스 범위 스캔 이터레이터가 검사한 로우 수를 항상 예상대로 증가시키지는 않았습니다. (Bug #33305632)
- 명령줄에서 `create_admin_listener_thread` 시스템 변수를 활성화하면 특정 오류 조건에서 시작 중 서버가 종료될 수 있었습니다. (Bug #33300587)
- [`SUBSTR()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_substr) 함수가 인수를 평가하려고 할 때 발생한 오류를 항상 올바르게 처리하지는 않았습니다. (Bug #33290160)
- International Components for Unicode 버전 67에서는 `\X`(grapheme cluster 일치)에 대한 새 구현을 도입했으며, 이 구현에는 현재 MySQL에 포함되어 있지 않은 locale 데이터가 필요합니다.

  이는 MySQL에 번들로 제공되는 ICU 버전을 사용할 때 `\X`를 사용하는 쿼리가 [`ER_REGEXP_MISSING_RESOURCE`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_regexp_missing_resource) 오류를 발생시킨다는 의미입니다. 시스템에서 제공하는 ICU를 사용할 때는 [`ER_WARN_REGEXP_USING_DEFAULT`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_warn_regexp_using_default)를 Note로 보고합니다. (Bug #33290090)

- `BLACKHOLE` 스토리지 엔진에 저장된 테이블에서 선택된 쿼리 계획이 전문 인덱스 스캔을 사용한 전문 검색 쿼리는 빈 결과 집합을 반환하는 대신 오류를 발생시켰습니다. (Bug #33250020)
- Performance Schema가 반환한 `LOCK_TIME`은 과소 평가되어 로우 잠금에 소요된 시간과 여러 테이블을 잠글 때 소요된 시간이 누락되었습니다. 이 릴리스부터 `LOCK_TIME`은 다음을 고려합니다:

  - SQL TABLES에서 대기한 모든 시간
  - DATA locks에서 대기한 모든 시간

  이제 `LOCK_TIME`은 slow log와 Performance Schema에서 일관되게 보고됩니다. (Bug #33236909)
- **mysql** 클라이언트 프롬프트의 새 옵션 `\T`는 현재 세션이 트랜잭션 블록 내부에 있는 경우 별표(`*`)를 출력합니다. 이 옵션은 `--prompt` 명령줄 옵션, MySQL 옵션 파일 또는 `MYSQL_PS1` 환경 변수와 함께 사용할 수 있습니다. 기여해 준 Murakami Kohei에게 감사드립니다. (Bug #33214862, Bug #104598)
- `RANGE INTERVAL` 표현식의 상수 서브쿼리가 항상 올바르게 처리되지는 않았습니다. (Bug #33197418)
- `NULL`로 평가되는 Decimal 표현식이 항상 올바르게 처리되지는 않았습니다. (Bug #33169048)

- 전역 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_select) 권한이 있는 MySQL 역할을 부여받은 사용자 계정이 `mysql` 데이터베이스에 대한 액세스를 거부당했습니다. 역할이 부여될 때 사용자 계정의 전역 권한이 확인되지 않았습니다. (Bug #33159353, Bug #104423)
- [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 별칭에 대한 `Item_ref`를 설정할 때, 해당 캐시된 속성(여기에는 `ROLLUP` 표현식의 일부인지 여부가 포함됩니다)이 복사됩니다. 그러나 이 속성들이 아직 올바르게 계산되지 않았을 수 있으므로, 먼저 계산을 수행해야 하며 그렇지 않으면 값이 잘못될 수 있습니다. 잘못된 값을 가지면 특정 표현식이 중간 단계에서 구체화될 수 있으며, 원래는 그렇게 되지 않아야 합니다(해당 표현식에 아직 계산할 준비가 되지 않은 `ROLLUP` 표현식이 포함되어 있기 때문이지만, 이 시점에는 값이 잘못되었는지 알 수 없습니다). 이 문제는 항목이 rollup 항목으로 지정될 때 캐시된 값이 강제로 다시 계산되도록 하여 수정되었습니다. (Bug #33149402, Bug #104394)
- MySQL 5.7에서 MySQL 8.0으로 테이블을 업그레이드하는 동안 감지된 유효하지 않은 주석 문자열로 인해 업그레이드가 실패했으며, 이때 충분한 문맥 정보를 제공하지 않는 오류가 발생했습니다. (Bug #33148961)
- 일부 경우에 허용되지 않는 `SERIAL` 타입의 생성 컬럼을 생성할 수 있었습니다.

  자세한 내용은 [Numeric Data Type Syntax](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/numeric-type-syntax.html) 및 [CREATE TABLE and Generated Columns](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table-generated-columns.html)를 참조하십시오(Bug #33141966).

- 트랜잭션을 암시적으로 또는 명시적으로 커밋하는 문은 트리거나 저장 함수 안에서 허용되지 않습니다. [`CREATE TRIGGER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-trigger.html)와 [`CREATE FUNCTION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-function.html)은 모두 이 경우 오류([`ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_commit_not_allowed_in_sf_or_trg))를 보고해야 하지만, [`DROP TABLESPACE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/drop-tablespace.html)를 올바르게 처리하지 않았습니다. (Bug #33141958)
- 매우 큰 `AVG_ROW_LENGTH` 값으로 정의된 테이블에서 [`SHOW TABLE STATUS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-table-status.html) 작업을 실행하면 assertion failure가 발생했습니다. (Bug #33114368)
- 스캔에서 읽을 가능성이 있는 최대 로우 수를 계산할 때, 중간 결과는 64비트 부호 없는 정수에 허용되는 최대값보다 커질 수 있는 double이었습니다. 이로 인해 중간 double 값을 정수로 변환할 때 정의되지 않은 동작이 트리거되었으며, 일부 경우 assert failure로 이어질 수 있었습니다.

  결과를 [1, `UINT64_MAX`] 범위로 고정하여 이 문제를 수정합니다. (Bug #33066458)

- `UNION`과 `LIMIT 0`을 모두 사용하는 쿼리는 디버그 빌드에서 assert 실패를 트리거했습니다. (Bug #33066455)

  참조: 이 문제는 다음의 회귀입니다: Bug #32302724.
- [`ALTER EVENT... RENAME TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-event.html)를 사용하여 이벤트 이름을 변경할 때 원래 이벤트에 대한 Performance Schema instrumentation이 삭제되지 않았습니다. (Bug #33059358)
- thread pool 플러그인을 사용할 때 디버그 빌드에서 SSL handshake assertion이 발생했습니다. (Bug #33012398)
- `GROUP BY WITH ROLLUP` 또는 하나 이상의 window 함수를 사용하는 일부 prepared statement는 한 번만 성공적으로 실행될 수 있었습니다. (Bug #33007266)
- [`INSERT INTO view VALUE(tuple) AS row_alias(id_list)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/insert.html) 형식의 문에서 오류가 발생했습니다. 이러한 문을 실행할 때 서버는 `VALUES` alias로 생성된 파생 테이블을 준비하기 위해 내부 함수 `Sql_cmd_insert_base::prepare_values_table()`을 호출합니다. 이 함수는 기반 테이블의 컬럼을 가리키는 `Item_field` 객체로 `Sql_cmd_insert_base.values_field_list`를 채웁니다. 테이블이 아니라 뷰에 삽입할 때, 뷰 컬럼을 참조하는 `Item_view_ref`에서 기반 테이블의 해당 컬럼을 나타내는 `Item_field`로 매핑하는 데 필요한 예상된 `real_item()` transform이 수행되지 않았습니다. (Bug #32858783)

- 일부 여러 겹으로 중첩된 subselect가 올바르게 처리되지 않았으며, 서버의 계획되지 않은 종료로 이어질 수 있었습니다. (Bug #32547812)
- `SHOW PROCESSLIST` 작업 중 세션 스레드 객체를 검사하는 것과 스레드의 보안 컨텍스트에 대한 동시 변경이 경합 조건을 초래했습니다. (Bug #32320541, Bug #102052)
- [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html)의 결과에 대해 수행할 작업이 없는 경우, 임시 테이블에 로우를 저장하지 않고 스트리밍하지만, 임시 테이블의 자리 표시자는 여전히 쿼리 블록에 존재합니다. 이 테이블은 인스턴스화되지 않으므로, 액세스 비용을 계산하고 range 기반 액세스를 최적화하는 동안 테이블에서 로우를 읽는 비용 추정치를 확인하면 예측할 수 없는 결과가 발생했습니다.

  인스턴스화되지 않은 임시 테이블의 경우 이러한 로우 추정치 검색을 건너뛰도록 하여 이 문제를 수정했습니다. (Bug #32255904)
- common table expression을 사용하는 다중 테이블 [`DELETE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/delete.html) 문이 항상 올바르게 처리되지는 않았습니다. (Bug #32238558)

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

- [`CR_UNKNOWN_ERROR`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/client-error-reference.html#error_cr_unknown_error)가 클라이언트로 전송될 예정인 경우 예외가 발생할 수 있었습니다. (Bug #31933415)
- 잠재적인 메모리 누수를 방지하기 위해 SSL 관련 코드가 수정되었습니다. (Bug #31933295)
- 일부 경우에, 다중 테이블 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html) 문이 동시 접근을 차단할 수 있었습니다. (Bug #31731752)
- 복잡한 설정에 내부 슬롯을 사용하는 Keyring 시스템 변수는 더 이상 `DEFAULT` 설정을 허용하지 않습니다. (Bug #30879700)
- `mysql.tables_priv` 및 `myql.columns_priv` 권한 테이블의 `Timestamp` 컬럼은 [`GRANT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/grant.html) 및 [`REVOKE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/revoke.html) 작업에 대해 0 타임스탬프 값(`"0000-00-00 00:00:00"`)으로 설정되어 권한 테이블의 논리적 복원을 방해했습니다. MySQL 8.0.28부터는 유효한 시작 시간 값이 Timestamp 컬럼에 기록됩니다.

  권한 테이블의 논리적 복원을 방해하는 0 타임스탬프 값이 있는 기존 권한 테이블 레코드가 있는 경우, 해결 방법은 권한 테이블 또는 덤프 파일의 레코드를 업데이트하여 0 타임스탬프 값을 [`CURRENT_TIMESTAMP`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_current-timestamp)로 바꾸는 것입니다.

  Venkatesh Prasad Venugopal의 기여에 감사드립니다. (Bug #30863899, Bug #98495)
- MySQL 5.7 및 8.0에서 **mysqldump**를 사용하여 테이블별 덤프를 생성하려면 MySQL 5.6에 비해 더 긴 실행 시간이 필요합니다. 이는 **mysqldump**가 로그 파일 그룹에 대한 정보를 쿼리하는 `information_schema.files` 테이블에 MySQL 5.7부터 NDB 데이터 파일뿐만 아니라 InnoDB 데이터 파일에 대한 정보도 포함되기 때문입니다. MySQL 8.0에서는 적절한 데이터 파일만 선택하도록 쿼리를 다시 작성하여 이 문제가 수정되었습니다. MySQL 5.7에서는 Information Schema 테이블에 인덱스가 없으므로, 여전히 전체 테이블 스캔이 필요합니다. (Bug #29210990, Bug #93875)
- Keyring 메모리 관리가 개선되었습니다. (Bug #25042167)
- 테이블 내 `FORCE INDEX` 힌트의 존재 여부를 저장하고 복원하는 동안 `FORCE INDEX FOR GROUP BY`에 대한 잘못된 값이 설정될 수 있었습니다. (Bug #105694, Bug #33604416)
- [`sql_buffer_result`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_sql_buffer_result) 시스템 변수가 활성화된 쿼리가 단 하나의 로우만 반환하고, 그 결과를 테이블에 삽입하려는 시도가 이루어진 경우, 임시 테이블에서 출력을 설정하는 중 오류가 발생하여 데이터 예외가 생성될 수 있었습니다. (Bug #105351, Bug #33515752)

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

- 윈도잉을 위한 입력 결과 집합의 끝에서 `WindowIterator::Read()`에서 활성 슬라이스 재설정이 수행되지 않았습니다. 이로 인해 `ORDER BY` 정렬에 도달했을 때 잘못된 값을 읽게 되었는데, 활성 슬라이스의 번호가 여전히 1, 즉 입력 테이블에서 읽는 항목으로 설정되어 있었기 때문이며, 반면 `ORDER BY` 정렬 단계는 모든 윈도우 함수 계산 이후의 값을 읽어야 합니다. 이를 위해서는 활성 슬라이스가 마지막 윈도우의 출력 테이블에 해당하는 슬라이스여야 합니다.

  읽기 직후 출력 슬라이스로 슬라이스 재설정을 이동하여 이 문제를 수정하므로, 입력 집합의 끝에서 반환하고 정렬로 이동할 때 이미 올바르게 설정되어 있습니다.

  기여해 주신 Casa Zhang 및 Tencent 팀에 감사드립니다. (Bug #105045, Bug #33399696)
- 코드 검사 결과, 내부 함수 `set_parse_error_message()`에서 복사 대상 버퍼의 마지막 바이트가 널 바이트인지 확인하지 않고 `strncpy()`를 사용하는 것이 발견되었습니다. `strncpy()` 대신 `snprintf()`를 사용하여 이 문제를 수정합니다. 이렇게 하면 결과가 잘리더라도 유효함이 보장됩니다. (Bug #104856, Bug #33321787)

- `DEFINER` 절(또는 저장 함수)로 생성된 트리거를 활성화한 prepared statement를 실행할 때, 테이블 접근을 확인하는 데 definer 권한 대신 invoker 권한이 사용되었습니다. 이로 인해 트리거 또는 저장 함수에서 사용하는 테이블에 대한 권한 검사가 실패할 수 있었습니다. (Bug #104168, Bug #33064461)
- singleton 히스토그램을 구성할 때 누적 빈도는 이전 버킷의 빈도를 현재 버킷과 더하여 계산됩니다. accumulator에 부동 소수점 값이 사용되었기 때문에, 이로 인해 때때로 누적된 float 오류가 발생하여 최종 누적 빈도가 1.0보다 미세하게 큰 값이 되었습니다.

  이 수정에서는 중간 부동 소수점 오류를 피하기 위해 대신 integer 타입으로 빈도를 누적합니다.

  기여해 주신 Casa Zhang 및 Tencent 팀에 감사드립니다. (Bug #104108, Bug #33045336)
- [`index_condition_pushdown=ON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_optimizer_switch) 및 [`transaction_isolation='READ-COMMITTED'`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_transaction_isolation)인 경우, 보조 인덱스가 일치하지 않았음에도 보조 인덱스의 잠금이 트랜잭션이 커밋되거나 롤백될 때까지 해제되지 않았습니다. (Bug #102722, Bug #32554667)

- 다중 값 인덱스가 저장 함수 내에서 실행된 쿼리에 사용되지 않았습니다. (Bug #102359, Bug #32427727)

  참조: 다음도 참조하십시오: Bug #104700, Bug #33268466.
- 여기에 표시된 형식을 가진 SQL 문에서 오류가 발생했습니다:

  ```
  INSERT INTO target_table
    SELECT aggregate_expression, non_aggregate_expression
    FROM empty_table;
  ```

  이는 쿼리 플랜이 임시 테이블의 집계를 사용하고, *`non_aggregate_expression`*이 쿼리의 한 실행 중에는 상수였지만 실행 간에는 달라질 수 있을 때 발생했습니다. 예를 들어 이러한 표현식에는 [`NOW()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_now) 또는 [`USER()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-functions.html#function_user)와 같은 함수가 포함될 수 있습니다. 이로 인해 임시 테이블에 *`non_aggregate_expression`*에 대한 컬럼이 생겼으며, 모든 로우가 같은 값을 가지므로 이는 불필요합니다. 또한 로우가 없는 경우에는 *`target_table`*에 삽입할 수 있는 적법한 값이 없었으며, 이것이 실제로 오류를 유발했습니다.

  현재 실행에서 *`non_aggregate_expression`*이 `const`일 때 임시 테이블 컬럼을 사용하지 않도록 하여 이 문제를 수정했습니다. (Bug #102252, Bug #32384355, Bug #33546083)

- 문자열로 전달된 값을 포함하는 prepared statement를 실행할 때, MySQL은 해당 값을 정수로 파싱하려고 시도했으며 입력 값과 관련 없는 오류를 반환할 수 있었습니다.

  최근 변경 이후, 파라미터에 대해 파생되는 데이터 타입이 컨텍스트를 기준으로 결정되도록 동적 파라미터 처리가 리팩터링되었습니다. 예를 들어 `int_col = ?`와 같은 비교에서, 파라미터에는 비교 대상인 (정수) 컬럼과 동일한 타입이 지정되었습니다. 기존 MySQL 애플리케이션과의 호환성을 유지하기 위해, decimal 또는 float 값이 파라미터로 제공되면 실제 값을 기준으로 파라미터에 새 타입을 할당하여 statement가 자동으로 재준비되었습니다. 이 처리는 숫자 파라미터에 대한 호환성을 유지했습니다.

  그러나 문자열 파라미터가 제공된 경우, 여전히 정수(해석된 데이터 타입)로 해석되었으며 이 동작은 값의 실제 타입을 감지하던 이전 MySQL 버전과 호환되지 않았습니다. 그 결과 `int_col = ?`가 파라미터 값 `'1.7'`로 실행되면 문자열의 정수 부분만 사용되어 유효한 비교가 `int_col = 1`이 되었습니다.

  이 문제를 수정하기 위해, 이제 문자열 파라미터가 제공되면 해당 파라미터가 정수, decimal 또는 float 값인지 확인하도록 분석되고 파라미터의 실제 데이터 타입이 그에 따라 업데이트됩니다. 이후 실제 타입이 해석된 타입과 비교되며, 호환되지 않는 경우 statement가 새 실제 타입으로 재준비됩니다. 따라서 이전 statement는 이제 `int_col = 1.7`로 평가되며, 비교는 decimal 숫자를 사용하여 평가됩니다. (Bug #101806, Bug #32213576, Bug #103364, Bug #32787037)