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

## DBA를 위한 핵심 내용

MySQL 8.0.42는 이번 묶음 중 DBA가 가장 주의해서 봐야 하는 버전입니다. 새 서버 옵션 `--check-table-functions`가 도입되었고 기본값이 `ABORT`라서, 제약 조건·기본 표현식·파티셔닝 표현식·가상 컬럼에 SQL 함수를 사용하는 테이블이 업그레이드 중 문제를 일으키면 서버 업그레이드가 중단될 수 있습니다. 단순 패치가 아니라 업그레이드 사전 점검 절차에 직접 영향을 주는 릴리스입니다.

1. `--check-table-functions`는 SQL 함수 개선으로 인해 기존 테이블 표현식이 새 버전에서 오류를 내는 경우를 업그레이드 시점에 탐지합니다. 기본값 `ABORT`는 문제가 발견되면 업그레이드를 중단하므로, 해당 기능을 쓰는 테이블이 있는 환경에서는 운영 반영 전에 스테이징에서 업그레이드 로그를 반드시 확인해야 합니다. 필요 시 `WARN` 모드로 문제를 식별한 뒤 기존 버전에서 수정하는 절차를 준비하는 것이 좋습니다.
2. OpenSSL이 3.0.16으로 업데이트되었고, 이 버전에는 ECDSA 서명 타이밍 사이드채널 및 저수준 GF(2^m) elliptic curve 파라미터 처리 관련 보안 수정이 포함됩니다. 번들 OpenSSL을 사용하는 플랫폼에서는 MySQL 패치와 보안 패치가 함께 묶여 있다고 봐야 합니다. ([OpenSSL 3.0 변경 내역](https://github.com/openssl/openssl/blob/openssl-3.0/CHANGES.md))
3. Replication 측면에서는 바이너리 로그 트랜잭션 종속성 추적 구조가 더 적은 메모리를 사용하는 방식으로 변경되었습니다. 병렬 복제 성능과 메모리 사용량에 영향을 줄 수 있으므로, 쓰기량이 많은 복제 환경에서는 적용 지연과 메모리 사용량을 비교해볼 가치가 있습니다.
4. InnoDB와 공간 인덱스 관련 수정이 다수 포함되어 있습니다. `CHECK TABLE EXTENDED`가 공간 인덱스의 MBR 검증을 강화하고, 공간 인덱스 손상 오탐·redo log 복구·종료 중 크래시·메모리 누수 등이 수정되었습니다. GIS/공간 인덱스를 쓰는 서비스는 일반 테이블보다 더 신중히 검증해야 합니다.
5. Replication에서는 `HASH_SCAN` 로우 매칭과 CRC32 충돌 조건에서 레플리카의 `UPDATE`/`DELETE`가 불규칙하게 실패할 수 있던 문제가 포함되어 있습니다. 로우 기반 복제에서 설명하기 어려운 `ER_KEY_NOT_FOUND`가 있었던 환경이라면 이 릴리스를 주의 깊게 봐야 합니다.
6. 별도 웹 검색에서는 공식 릴리스노트 외에 이 버전 전용 대규모 회귀 보고는 확인하지 못했습니다. 다만 외부 블로그와 클라우드 벤더 문서에서도 8.0.42 릴리스 자체가 언급되며, DBA 관점에서는 `--check-table-functions` 기본 동작과 공간 인덱스·복제 수정이 핵심입니다.

## Audit Log 관련 사항

- `<COMMAND_CLASS>`가 `<NAME>Execute</NAME>`에 대해 채워지지 않았습니다.

  자세한 내용은 [특정 이벤트 클래스 로깅](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-filter-definitions.html#audit-log-filtering-class-logging)을 참조하십시오. (Bug #36686351)

## 컴파일 관련 사항

- **Group Replication:** OpenSSL Engine 인터페이스는 사용 중단되었으며, Fedora를 포함한 일부 Linux 배포판의 OpenSSL v3 기본 패키지에 더 이상 포함되지 않습니다.

  빌드 문제를 피하기 위해, Group Communication System (GCS)에서 OpenSSL Engine 인터페이스를 사용하는 것은 이제 1.1 이전의 OpenSSL 버전으로 제한됩니다. (Bug #37475769)
- **Linux:** Oracle Linux 10에서 서버를 빌드할 때 /usr/bin/gcc (GCC 14.2.1)를 사용합니다. (Bug #37616148)
- 번들로 제공되는 Curl 라이브러리를 버전 8.12.1로 업그레이드했습니다. (Bug #37633587)
- Abseil을 FreeBSD에서 빌드할 수 없었습니다. (Bug #37611924)
- `lz4` 라이브러리(번들 또는 소스)와 독립적으로 `xxhash` 함수를 사용하기 위해, `xxhash.c`를 자체 바이너리로 컴파일했으며, 이를 위해 매우 많은 CMake 지시문을 사용해야 했습니다. 대신 이제 `xxhash`용 인터페이스 라이브러리를 빌드하고, 이러한 함수가 사용되는 모든 위치에서 해당 라이브러리에 링크합니다. (Bug #37417386)
- lz4와 함께 번들로 제공되는 버전이 아니라 GitHub의 xxHash-0.8.2를 사용합니다. (Bug #37387318)

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

- **중요한 변경:** SQL 함수가 한 릴리스에서 다음 릴리스로 개선되면, 이전에는 발생시키지 않았던 상황에서 SQL 오류를 발생시킬 수 있습니다. 이 문제가 테이블의 제약 조건, 기본 표현식, 파티셔닝 표현식 또는 가상 컬럼에서 발생하면 해당 테이블을 열 수 없었습니다. 이로 인해 ([`SHOW CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-create-table.html) 사용과 같은) 문제 분석과 ([`ALTER TABLE... DROP...`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문 사용과 같은) 문제 해결이 모두 차단되었습니다.

  이제 서버 업그레이드 시 방금 언급한 기능 중 하나를 사용하는 테이블이 있는지 데이터 딕셔너리를 스캔합니다. 그런 다음 이러한 테이블을 열려고 시도하고, 열지 못하면 사용자에게 알립니다. 이 패치는 이 문제를 해결합니다. 이 릴리스에서 도입된 [`--check-table-functions`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-options.html#option_mysqld_check-table-functions) 서버 옵션은 이러한 함수에서 오류가 발생할 때 서버 동작을 지정할 수 있게 하여 이 문제를 해결하는 데 도움이 됩니다. 서버가 열 수 없었던 각 테이블에 대해 경고를 로그에 기록하려면 이 옵션을 `WARN`으로 설정하십시오. `ABORT`로 설정하면 이러한 경고도 `WARN`으로 로그에 기록하지만, 문제가 발견된 경우 서버 업그레이드를 중단합니다.

  `ABORT`가 기본값입니다. 이를 통해 사용자는 새 버전으로 업그레이드하기 전에 이전 버전의 서버를 사용하여 문제를 수정할 수 있습니다. `WARN`은 문제에 플래그를 지정하지만, 사용자가 문제를 해결하는 동안 대화형 모드에서 계속 진행할 수 있게 합니다. (Bug #36890891)

  참조: 다음도 참조하십시오: Bug #37009318. 이 문제는 다음의 회귀입니다: Bug #98950, Bug #98951, Bug #31031886, Bug #31031888.

## INFORMATION_SCHEMA 관련 사항

- [`PROCESSLIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-processlist-table.html) 테이블의 성능 문제가 수정되었습니다. (Bug #36778475)

## InnoDB 관련 사항

- **InnoDB:** InnoDB는 이제 병렬 스캔 중 레벨 1 진행 상황을 저장하고 복원하기 위해 단순화된 API를 사용합니다. (Bug #37517125)

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

- **중요한 변경:** OpenSSL 라이브러리가 번들로 제공되는 플랫폼의 경우, MySQL Server에 링크된 OpenSSL 라이브러리가 버전 3.0.16으로 업데이트되었습니다. 자세한 내용은 [OpenSSL 3.0 Series Release Notes](https://openssl-library.org/news/openssl-3.0-notes/) 및 [OpenSSL Security Advisory (11th February 2025)](https://openssl-library.org/news/secadv/20250211.txt)를 참조하십시오. (Bug #36033684)
- **Performance; Replication:** 바이너리 로그 트랜잭션 종속성을 추적하는 데 사용되는 데이터 구조가 `Tree`에서 `ankerl::unordered_dense::map`으로 변경되었으며, 이는 약 60% 더 적은 공간을 사용하므로 더 나은 종속성 추적 성능에 기여할 것으로 예상됩니다. (Bug #37008442, Bug #37529256)
- **InnoDB:** 디버깅을 개선하기 위해, 이제 `buf_page_t` 및 `buf_block_t` 구조체의 메타데이터가 오류 로그에 출력됩니다. (Bug #35115629)

  참조: 다음도 참조하십시오: Bug #35115601.
- signal 처리 중 현재 쿼리를 출력할 때 적용되던 기존 1024바이트 제한이 1073741824(1024 * 1024 * 1024)로 증가했습니다. (Bug #37603354)

## 수정된 버그

- **InnoDB:** innobase 코드의 여러 위치에서 발생할 수 있는 잠재적 메모리 누수를 수정했습니다. (Bug #37403052)
- **InnoDB:** 특정 상황에서 아직 fixed 상태이거나 dirty 상태인 페이지로 인해 MySQL이 종료 중 크래시될 수 있었습니다. 다음과 유사한 오류가 로그에 기록되었습니다:

  ```
  [ERROR] [MY-011908] [InnoDB] [FATAL] Page [page id: space=46, page number=75] still fixed or dirty
  [ERROR] [MY-013183] [InnoDB] Assertion failure: buf0buf.cc:5889:ib::fatal triggered thread 139963705668608
  ```

  (Bug #37391519)

  참조: 다음도 참조하십시오: Bug #35115601.
- **InnoDB:** 공간 인덱스에 대한 [`CHECK TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/check-table.html)은 클러스터형 인덱스 레코드에 저장된 geometry MBR에 대해 MBR을 검증하지 않았습니다. 이로 인해 공간 인덱스가 올바르지 않게 동작할 수 있었습니다.

  이 릴리스부터 `CHECK TABLE EXTENDED`는 MBR이 클러스터형 인덱스 레코드에 저장된 MBR과 일치하는지 검증합니다. (Bug #37359538)
- **InnoDB:** 비관적 로우 업데이트와 관련된 문제를 수정했습니다.

  기여해 주신 Alibaba의 Mengchu Shi 및 팀에 감사드립니다. (Bug #37292404)
- **InnoDB:** [`CHECK TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/check-table.html) 작업이 공간 인덱스의 손상을 잘못 보고할 수 있었습니다. (Bug #37286473)
- **InnoDB:** InnoDB redo log 복구와 관련된 문제를 수정했습니다. (Bug #37061960)

- **InnoDB:** `index_id` 값 읽기와 관련된 문제를 수정했습니다. (Bug #36993445, Bug #37709706)
- **InnoDB:** [`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 #32288105)
- **InnoDB:** 다른 클라이언트 세션에서 해당 테이블의 정의를 변경하는 동안 레코드 수를 조회할 때 파티션 테이블 인덱스가 확인되지 않았습니다. 레코드 수 조회가 오류 없이 실행되었습니다.

  이 릴리스부터 레코드 수를 조회할 때 인덱스를 확인하여 사용할 수 있는지 보장합니다. (Bug #117459, Bug #37617773)
- **InnoDB:** 복원 작업을 위한 BPR_PCUR_* 위치 지정과 관련된 코드를 리팩터링했습니다. (Bug #117259, Bug #37505746)

  참조: 이 문제는 다음의 회귀입니다: Bug #37318367.
- **InnoDB:** MySQL 8.0.30에서 [`innodb_spin_wait_delay`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_spin_wait_delay)에 적용된 변경 사항이 성능에 부정적인 영향을 주었습니다. (Bug #116463, Bug #37212019)

- **InnoDB:** 특정 상황에서 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html)을 `INPLACE`와 함께 사용하여 컬럼 크기를 수정하면 유효한 크기 제한(767바이트)을 초과하는 인덱스가 만들어질 수 있었습니다. 이는 로우 형식이 `Redundant` 또는 `Compact`인 테이블에서 발생했으며, 테이블 생성 시 로우 형식이 명시적으로 정의되지 않았습니다.

  이 릴리스부터는 잘못된 인덱스 크기를 초래하는 모든 ALTER TABLE, INPLACE 작업에 대해 검증이 수행되고 오류가 반환됩니다. (Bug #116353, Bug #37168132)
- **InnoDB:** `Clone_persist_gtid` 스레드의 메모리 누수를 수정했습니다.

  기여해 주신 Baolin Huang 및 Alibaba 팀에 감사드립니다. (Bug #107991, Bug #34454572)
- **파티셔닝:** 파티션된 테이블의 파티션 키에 포함되지 않은 컬럼에 [`NOW()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/date-and-time-functions.html#function_now)를 삽입할 때 모든 파티션이 검색되었고 프루닝이 발생하지 않았습니다. (Bug #37397306)

- **Replication:** 소스-레플리카 구성에서, 레플리카가 같은 테이블에 대해 [`ER_KEY_NOT_FOUND`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_key_not_found) 오류와 함께 [`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) 문에서 불규칙한 실패를 겪었습니다. (레플리카의 바이너리 로그와 GTID 레코드는 필요한 로우가 커밋되었으며, 삭제되거나 업데이트되지 않았음을 보여주었습니다.) 이는 레플리카에서 사용된 로우 매칭 알고리즘이 `HASH_SCAN`이고 같은 테이블의 두 로우가 같은 CRC32 값을 가질 때 발생했습니다.

  이러한 CRC32 충돌이 발생하는 경우, 해시 테이블에서 일치하는 CRC32를 찾는다고 해서 올바른 로우가 업데이트된다는 보장은 없으므로, 알고리즘은 같은 CRC32를 가진 여러 항목이 있으면 이를 반복 처리하고 루프에서 각 항목의 전체 레코드를 비교합니다. 문제는 이 루프를 종료하는 로직이 올바르지 않았기 때문에 발생했습니다. 이 로직은 이제 수정되었습니다. (Bug #37462058, Bug #37731216)

- **Replication:** [`asynchronous_connection_failover_delete_source()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-functions-async-failover.html#function_asynchronous-connection-failover-delete-source) 함수가 모든 경우에 항상 예상대로 동작하지는 않았습니다. (Bug #36479088)
- **Replication:** 일부 경우에 [`asynchronous_connection_failover_add_source()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-functions-async-failover.html#function_asynchronous-connection-failover-add-source) 함수가 예상대로 동작하지 않았습니다. (Bug #36479083)
- **Replication:** 일부 경우에 [`MASTER_POS_WAIT()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-functions-synchronization.html#function_master-pos-wait)가 예상대로 동작하지 않았습니다. (Bug #36421684, Bug #37709187)
- **Replication:** [`asynchronous_connection_failover_add_managed()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-functions-async-failover.html#function_asynchronous-connection-failover-add-managed) 함수가 일부 경우에 예상된 결과를 생성하지 않았습니다. (Bug #34648589)

- **Replication:** 서버가 높은 쓰기 부하 상태에 있을 때, Performance Schema [`log_status`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-log-status-table.html) 테이블에 표시되는 [`gtid_executed`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-gtids.html#sysvar_gtid_executed)의 바이너리 로그 위치가 바이너리 로그 파일에 표시되는 gtid의 위치와 일치하지 않았습니다.

  이를 수정하기 위해, 쿼리할 때 `log_status` 테이블에 대한 잠금 범위를 늘려 커밋 파이프라인의 트랜잭션이 완료되도록 했습니다. 이를 통해 `log_status` 테이블에 대한 쿼리가 `gtid_executed`가 완전히 업데이트될 때까지 대기하도록 하여, 바이너리 로그에서의 위치와 일관성이 보장됩니다. (Bug #102175, Bug #32442772)
- **Group Replication:** 보조 멤버가 그룹에 조인할 때, 모든 그룹 멤버에서 Performance Schema [`replication_group_member_stats`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-replication-group-member-stats-table.html) 테이블의 `COUNT_TRANSACTIONS_ROWS_VALIDATING` 컬럼 값이 무기한 증가하기 시작하는 경우가 있었습니다. 이는 모든 그룹 멤버의 메모리 사용량에 영향을 미쳤으며, 해당 동작을 유발한 보조 그룹 멤버를 재시작하거나 경우에 따라 전체 그룹을 재시작하여 완화하지 않으면 결국 스래싱으로 이어졌습니다.

  분석 결과, 이전 그룹 참여에서 `group_replication_applier` 채널에 부분 트랜잭션이 있는지 확인하는 Group Replication 시작 작업의 문제로 확인되었습니다. 부분 트랜잭션이 발견되면, 이 채널은 모든 완료된 트랜잭션을 적용한 후 중지되고 릴레이 로그가 제거된 다음, 채널이 재시작됩니다. 그 후 분산 복구가 수행되어 그룹 멤버에서 누락된 데이터가 적용됩니다.

  `group_replication_applier` 채널을 중지하기 위한 Group Replication 파이프라인 작업이 certifier 모듈의 주기적 작업을 잘못 중지하여 일부 주기적 내부 작업이 수행되지 않았을 때 문제가 발생했습니다. 이러한 작업 중 하나는 커밋된 트랜잭션의 주기적 전송이었으며, 이 누락으로 인해 certification을 위한 가비지 컬렉션이 방지되었고, 그 결과 Performance Schema `replication_group_member_stats` 테이블에서 `COUNT_TRANSACTIONS_ROWS_VALIDATING`이 지속적으로 증가했습니다.

  이 문제를 해결하기 위해, `group_replication_applier` 채널을 중지하기 위한 파이프라인 작업이 더 이상 certifier 모듈을 방해하지 않도록 하는 조치를 취했으며, 이로 인해 `COUNT_TRANSACTIONS_ROWS_VALIDATING`에 잘못된 값이 추가되는 것도 중지됩니다. (Bug #37613510)
- **Group Replication:** Group Replication을 실행할 때, GTID_NEXT가 지정된 빈 트랜잭션 또는 DDL 문과 같이 일부 트랜잭션에는 write set이 없을 수 있습니다. 이러한 트랜잭션의 경우 Group Replication은 충돌을 확인할 수 없으므로, 병렬로 적용될 수 있는지 여부를 알 수 없으며, 이러한 이유로 Group Replication은 비관적인 접근 방식을 따르고 이를 순차적으로 실행하여 성능에 영향을 줄 수 있습니다.

  DDL은 순차적으로 적용되어야 하지만, 빈 트랜잭션에 대해 이러한 동작을 강제할 실제 이유는 없으므로, 이 수정으로 빈 트랜잭션을 다른 비종속 트랜잭션과 동시에 적용할 수 있게 됩니다. (Bug #37597512, Bug #37569333)

- **Group Replication:** 프라이머리 `i1`과 두 세컨더리 `i2` 및 `i3`로 Group Replication을 실행 중인 그룹에서 프라이머리의 높은 메모리 사용량 때문에 간헐적인 문제가 발생하기 시작했습니다. 세컨더리는 프라이머리를 도달할 수 없는 상태로 보고한 다음 다시 도달 가능한 상태로 보고하기 시작했으며, 프라이머리도 세컨더리를 간헐적으로 도달 가능한 상태로 보고한 다음 다시 도달 가능한 상태로 보고하기 시작했습니다. 이러한 불안정 기간이 지난 후, 세컨더리는 원래 프라이머리(`i1`)를 축출하고 새 프라이머리(`i2`)를 선출했습니다.

  이러한 조건에서 이전 프라이머리(`i1`)에서 [`performance_schema.replication_group_members`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-replication-group-members-table.html) 테이블에 대해 실행한 쿼리는 `i1`을 `ONLINE` 및 `PRIMARY`로, `i2`를 `ONLINE` 및 `SECONDARY`로, `i3`을 `ONLINE` 및 `SECONDARY`로, `i1`에서 **mysqld** 프로세스가 재시작될 때까지 장기간(12시간 이상) 보고했습니다.

  관찰된 문제는 원래 프라이머리(`i1`)에서 세컨더리 중 하나가 과부하되어 그룹을 간헐적으로 떠났다가 다시 참여하기 시작하고, 해당 연결이 프라이머리 서버에서 반복적으로 끊어지고 다시 생성될 때 시작된 것으로 확인되었습니다. 재연결 프로세스 중에 프라이머리는 연결 생성을 시도할 때 중단되었고, 그 결과 단일 XCom 스레드가 차단되었습니다. 이는 XCom 통신 스택에서 `SSL_connect()` 호출로 추적되었으며, 이 호출은 MySQL 8.0.27에서 비동기 형식에서 동기 형식으로 변경되었습니다. 노드가 과부하된 경우 `SSL_connect()` 호출에 응답하지 않을 수 있었고, 연결하는 쪽이 무기한 차단된 상태로 남았습니다.

  이 문제를 해결하기 위해 이제 비차단 방식으로 연결하고, 타임아웃이 발생하면 반환하여 재시도 시도를 호출자에게 맡기도록 했습니다. 이 특정 경우에는 다른 노드에 다시 연결하려고 시도할 때의 XCom 스레드입니다. (Bug #34348094, Bug #36047891)

  참조: 다음도 참조하십시오: Bug #37587252.
- **mysqldump**의 `fprintf_string()` 함수가 문자열 이스케이프에 실제 따옴표 문자를 사용하지 않았습니다. (Bug #37607195)
- [`EXPLAIN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html)이 서브쿼리를 항상 올바르게 처리하지는 않았습니다. (Bug #37560280)
- 스택 추적에서 디맹글된 함수 이름이 512바이트를 초과하면, 함수 이름이 잘리고 개행 문자가 출력되지 않았습니다.

  이 릴리스부터는 파일 이름 및 디맹글된 함수와 같은 긴 문자열이 출력에 직접 기록됩니다. (Bug #37543598)
- **mysqldump**가 출력에서 특정 특수 문자를 올바르게 이스케이프하지 않았습니다. 이 수정으로 **mysqldump**는 이제 [String Literals](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-literals.html)에 설명된 규칙을 따릅니다. (Bug #37540722, Bug #37709163)
- 함수형 인덱스가 있는 테이블에 대한 일부 작업이 올바르게 처리되지 않았습니다. (Bug #37523857)
- [`INSTALL COMPONENT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/install-component.html)를 사용하여 알 수 없는 컴포넌트를 설치하려는 시도가 항상 올바르게 처리되지는 않았습니다. (Bug #37437317)

- Audit Log 플러그인은 JSON 출력을 작성할 때 오류를 올바르게 처리하지 못했습니다.

  자세한 내용은 [MySQL Enterprise Audit](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log.html)을 참조하십시오. (Bug #37370439)
- `BEFORE INSERT` 트리거가 있는 테이블에 영향을 주는 [`INSERT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/insert.html) 이후의 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html)는, 유효한 서버 [`sql_mode`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_sql_mode)에 의해 허용되어야 했음에도 불구하고, `INSERT`가 `NOT NULL` 컬럼을 `NULL`로 설정한 경우 null 값 오류와 함께 거부되는 경우가 있었습니다. (Bug #37337527)
- 일부 경우에 컴포넌트가 여러 쿼리를 실행하기 위해 동일한 연결을 재사용할 수 없었습니다. (Bug #37286895)
- 저장 루틴에 대한 오류 처리가 개선되었습니다. (Bug #37193011)
- 저장 루틴이 prepared statement에서 항상 올바르게 호출되지는 않았습니다. (Bug #37077424, Bug #37292797)
- `SEL_ROOT::elements`의 크기가 `uint16`에서 `size_t`로 증가했습니다. (Bug #36610878)
- 멀티바이트 UTF8 처리와 관련된 문제가 제거되었습니다. (Bug #36593253)
- 집계를 포함하는 `ORDER BY`가 항상 올바르게 처리되지는 않았습니다. (Bug #36593244)

- [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html)을 포함하는 뷰를 쿼리할 때 optimizer hint가 무시되어, 예기치 않게 `FORCE INDEX`를 사용해야 했습니다. 자세한 내용은 [Optimizer Hints](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/optimizer-hints.html)를 참조하십시오. (Bug #36536936)
- 일부 서브셀렉트가 올바르게 처리되지 않았습니다. (Bug #36421690)
- 특정 경우에 유효하지 않은 DDL 문이 예상대로 항상 거부되지는 않았습니다. (Bug #35721121)
- 내부 함수 `append_identifier()`를 개선했습니다. (Bug #35633084)
- 일반적으로 사용되지 않는 윈도우 정의가 있는 뷰는 업데이트 가능해야 하지만, 서브쿼리를 포함하는 경우 업데이트 불가능한 것으로 표시되었습니다. 업데이트 시점에는 윈도우가 제거되었지만, 이는 업데이트 수행을 허용하기에는 너무 늦었습니다.

  윈도우 정의의 존재 여부가 아니라 윈도우 함수의 존재 여부를 확인하여 병합 가능성을 테스트하는 방식으로 이 문제를 수정했습니다. 이를 통해 뷰가 업데이트 가능해지고, 문제가 있던 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html)가 성공할 수 있습니다. (Bug #35507777)
- 일부 경우에 [`SET`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set.html)이 prepared statement에서 올바르게 수행되지 않았습니다. (Bug #35308309)
- 이 수정은 다음 문제를 해결합니다:

  - `Query_expression::is_set_operation()`이 항상 올바르게 실행되지는 않았습니다.

- 일부 DML 문 시퀀스가 계획되지 않은 종료로 이어질 수 있었습니다.
  - 일부 중첩된 서브셀렉트가 항상 올바르게 처리되지는 않았습니다.

  (Bug #34361287, Bug #35889583, Bug #35996409, Bug #36404149, Bug #36863048, Bug #37611264)

- Debian에서 **dh_strip_nondeterminism**은 더 이상 패키지 내 zip 및 gzip 파일에 대해 실행되지 않습니다. (Bug #33791880)
- 유효하지 않은 UTF8 값과 관련된 문제를 제거했습니다. (Bug #27618273, Bug #37709687)
- 유효하지 않은 식별자와 관련된 문제를 처리했습니다. (Bug #22958632, Bug #37709664)
- 쿼리에서 `ORDER BY DESC` 및 `LIMIT`와 함께 다중값 인덱스를 사용할 때 성능에 부정적인 영향이 관찰되었으며, 이때 `LIMIT`에 지정된 값은 실제로 결과에 있는 로우 수보다 컸습니다. (Bug #117085, Bug #37436310)

  참조: 이 문제는 다음의 회귀입니다: Bug #104897, Bug #33334911.
- 조건을 파생 테이블로 푸시다운할 때 조건을 복제하며, 기반 필드가 뷰 참조(즉, 병합된 파생 테이블의 필드)인 경우 뷰 참조를 제거하고 그것이 참조하는 표현식을 복제합니다. 기반 표현식이 외부 조인의 내부 쪽에 있는 테이블의 상수 표현식인 경우 `NULL` 값을 생성해야 하므로 일반 상수로 처리할 수 없습니다. 뷰 참조를 제거했을 때 이 정보가 손실되어 잘못된 결과로 이어졌습니다.

  이러한 경우에 조건 푸시다운을 피하도록 하여 이 문제를 수정했습니다. (Bug #111355, Bug #35634714)