DBA를 위한 핵심 내용

MySQL 8.0.27은 MFA 도입, 복제 멀티스레드 적용자 기본 활성화, GTID_ONLY, Group Replication 통신/장애조치 개선, InnoDB 온라인 DDL 병렬화 등 운영 동작 기본값이 크게 바뀐 릴리스입니다. 외부적으로는 Google Cloud가 8.0.27~8.0.31에서 저장 프로시저 실행 관련 메모리 누수 가능성을 알려 8.0.32 이상 업그레이드를 권고합니다. 따라서 이 버전은 복제 지연 개선 효과가 있지만, 메모리 관측과 복제 커밋 순서 검증을 포함해 단계적으로 적용하는 것이 안전합니다. (Google Cloud known issues)

레플리카의 멀티스레드 적용자가 기본값(replica_parallel_workers=4, replica_preserve_commit_order=1, replica_parallel_type=LOGICAL_CLOCK)으로 활성화됩니다. 기존 단일 스레드 적용을 전제로 한 지연 분석, 장애 복구 절차, 모니터링 임계값을 재조정해야 합니다.
GTID_ONLY 복제 채널 옵션이 추가되며 Group Replication 채널에서는 기본 활성화됩니다. GTID, row-based logging, SOURCE_AUTO_POSITION, REQUIRE_ROW_FORMAT 전제 조건을 만족하지 않으면 적용할 수 없으므로 채널별 사전 점검이 필요합니다.
Group Replication은 stop timeout 기본값이 365일에서 300초로 바뀌고, MySQL communication stack, single-primary Paxos single leader, managed async failover가 추가되었습니다. 장애 상황에서 멈춤을 줄이는 대신 권한(GROUP_REPLICATION_STREAM), TLS, bind_address/local address 정합성 검증이 중요해졌습니다.
InnoDB 온라인 DDL에 innodb_ddl_threads, innodb_ddl_buffer_size가 추가되어 인덱스 빌드를 병렬화할 수 있습니다. 대형 테이블 DDL 속도 개선 여지가 있지만 I/O 병목, 메모리 한도, 복제 지연 증가를 함께 관찰해야 합니다.
default_authentication_plugin과 BINARY 연산자가 사용 중단되고 MFA 및 authentication_policy가 도입되었습니다. 계정 생성 자동화, 커넥터/클라이언트 비밀번호 옵션, 감사 로그·권한 정책을 새 인증 모델에 맞춰 검증해야 합니다.

Audit Log 관련 사항

CREATE USER 문의 BY 'auth_string' 절이 audit log 및 general query log에 AS 'auth_string' 절로 기록되었습니다. (Bug #33184550)

Authentication 관련 사항

이전에는 MySQL 사용자 계정이 단일 인증 방법을 사용하여 서버에 인증했습니다. 이제 MySQL은 다중 인증(MFA)을 지원하며, 이를 통해 최대 세 가지 인증 방법을 가진 계정을 생성할 수 있습니다. MFA 지원에는 다음 변경 사항이 포함됩니다:
- CREATE USER 및 ALTER USER 문법이 여러 인증 방법의 지정을 허용하도록 확장되었습니다.
- authentication_policy 시스템 변수는 사용할 수 있는 factor 수와 각 factor에 허용되는 인증 유형을 제어하여 MFA 정책을 설정할 수 있게 합니다. 이는 CREATE USER 및 ALTER USER 문의 인증 관련 절을 사용하는 방법에 제약을 둡니다.
- 클라이언트 프로그램에는 여러 비밀번호를 지정하기 위한 새로운 --password1, --password2, --password3 명령줄 옵션이 있습니다. C API를 사용하는 애플리케이션의 경우, mysql_options4() C API 함수에 대한 새로운 MYSQL_OPT_USER_PASSWORD 옵션이 동일한 기능을 제공합니다.
또한 MySQL Enterprise Edition은 이제 스마트 카드, 보안 키, 생체 인식 리더와 같은 장치를 사용한 MySQL Server 인증을 지원합니다. 이 인증 방법은 Fast Identity Online (FIDO) 표준을 기반으로 하며, 서버 측의 authentication_fido와 클라이언트 측의 authentication_fido_client라는 한 쌍의 플러그인을 사용합니다. 서버 측 FIDO 인증 플러그인은 MySQL Enterprise Edition 배포판에만 포함됩니다.

다중 인증은 기존 MySQL 인증 방법, 새로운 FIDO 인증 방법 또는 둘의 조합을 사용할 수 있습니다. 자세한 내용은 Multifactor Authentication을 참조하십시오. (Bug #33159968, WL #14183)
인증 플러그인이 인증 문자열의 해싱을 수행하지 않는 경우, BY 'auth_string' 절이 있는 CREATE USER 문은 오류와 함께 실패했습니다. (Bug #33125289)

캐릭터셋 지원

정규 표현식 함수는 이제 표현식 또는 패턴을 ICU 정규 표현식 엔진에 적합한 캐릭터셋으로 변환할 수 없는 경우 오류를 보고합니다.

또한 여러 geometry 함수의 오류 검사가 개선되었습니다. (Bug #33290245)
gen_dictionary() 함수는 이제 인수의 캐릭터셋으로 latin1을 사용하며, 동일한 캐릭터셋을 반환합니다. (Bug #30389649)
각각 ASCII(콜레이션 ascii_general_ci) 및 UCS2(콜레이션 ucs2_general_ci) 캐릭터셋을 사용하는, 그 외에는 동일한 문자열이 조인 조건에서 예상대로 일치하지 않았습니다. (Bug #104571, Bug #33204161)

참조: 다음도 참조하십시오: Bug #24847620, Bug #30746908, Bug #32244631, Bug #32501472.
캐릭터셋 cs의 기본 콜레이션 c1과 다른 콜레이션 c2(c1과 같지 않음)가 주어진 경우, 명령문 CREATE DATABASE d COLLATE c2 CHARACTER SET cs는 기본 콜레이션이 c2 대신 c1로 설정된 새 데이터베이스를 생성했습니다. (Bug #104504, Bug #33183590)

컴파일 관련 사항

InnoDB: Windows에서 빌드 실패를 일으키는 Clang 문제에 대한 우회 방법이 구현되었습니다(Bugzilla – Bug 51538). (Bug #33217633)
이제 MySQL은 C++17을 사용하여 컴파일할 수 있습니다. 컴파일러 지원에는 다음 최소 버전 요구 사항이 적용됩니다:
- GCC 7.1 또는 Clang 5 (Linux)
- XCode 10 (macOS)
- GCC 10 (Solaris)
- Visual Studio 2019 Update 4 (Windows)
특히 Solaris에서는 이제 GCC가 유일하게 지원되는 컴파일러입니다. Sun Studio, Oracle Studio 및 SunPro에 대한 조정 및 우회 방법을 제거하도록 코드가 정리되었습니다. (Bug #32907274, Bug #103757, Bug #32907475, Bug #32992125, Bug #32992242, Bug #33004840, Bug #33086882)

연결 관리 관련 사항

이전에는 서버가 만료된 비밀번호가 있는 계정에 대한 클라이언트 연결을 처리하는 데 사용되는 sandbox mode로 클라이언트를 제한한 경우, 클라이언트가 SET 문을 사용할 수 있었습니다. 이제 이는 더 이상 허용되지 않습니다. sandbox mode에 대한 자세한 내용은 Server Handling of Expired Passwords를 참조하십시오. (Bug #16369085, WL #13214)

데이터 딕셔너리 관련 사항

YEAR 값이 항상 올바르게 해석되지는 않았습니다. (Bug #33142669)

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

사용 중단 및 제거 관련 사항

중요한 변경: default_authentication_plugin 변수는 MySQL 8.0.27부터 사용 중단되며, 향후 MySQL 버전에서 이에 대한 지원이 제거될 것으로 예상하십시오.

default_authentication_plugin 변수는 MySQL 8.0.27에서도 여전히 사용되지만, 다중 인증 기능과 함께 MySQL 8.0.27에 도입된 새 authentication_policy 시스템 변수와 함께, 그리고 그보다 낮은 우선순위로 사용됩니다. 자세한 내용은 The Default Authentication Plugin을 참조하십시오. (Bug #27515356, WL #14138)
중요한 변경: BINARY 연산자는 이제 사용 중단되며, 향후 MySQL 릴리스에서 제거될 수 있습니다. 이제 BINARY를 사용하면 경고가 발생합니다. 대신 CAST(... AS BINARY)를 사용하십시오. (WL #13619)

Storage Engine 관련 사항

BLACKHOLE 스토리지 엔진의 최대 키 길이가 1000바이트에서 3072바이트(InnoDB와 동일)로 증가했습니다. 기여해 주신 Adam Cable에게 감사드립니다. (Bug #32788749, Bug #103371)

Firewall 관련 사항

새로운 FIREWALL_EXEMPT 권한은 사용자가 Firewall 제한에서 제외되도록 합니다. 이는 예를 들어 Firewall을 설정하는 데이터베이스 관리자에게 유용하며, 잘못된 설정으로 인해 관리자까지 잠겨서 문을 실행할 수 없게 되는 가능성을 방지합니다. MySQL Enterprise Firewall을 참조하십시오. (WL #14517)

SQL 함수 및 연산자 관련 사항

SPACE() 함수가 특정 큰 값 또는 부호 없는 값을 올바르게 처리하지 못했습니다. (Bug #33180446)
뷰 내에 정의된 함수의 해석 중에 함수 인수가 항상 올바르게 평가되지는 않았습니다. (Bug #33142010)

참조: 이 문제는 다음의 회귀입니다: Bug #29904087.
윈도우 표현식의 비트 함수는 비트 마스크의 런타임 크기가 해석 시점 크기보다 크지 않다고 단언합니다. 이 규칙을 위반하는 여러 사례가 발견되었으며, 여기에 나열합니다:
- ENCRYPT()는 때때로 결과의 최대 크기를 잘못 계산했습니다.
- CONVERT(), CONCAT(), CONCAT_WS(), EXPORT_SET(), INSERT(), REPLACE(), 및 WEIGHT_STRING()은 바이너리 캐릭터셋에 대해 최대 결과 길이를 적절하게 계산하지 못했습니다.
- REPLACE(str, from_str, to_str)의 해석 중에 from_str의 전체 길이가 str의 각 일치 항목마다 대체된다고 가정했지만, from_str는 1자 길이일 수 있으므로 str가 to_str의 여러 복사본으로 대체될 수 있습니다.
- COMPRESS()는 최대 결과 길이를 임의의 방식으로 계산했습니다. 이제 대신 zlib 라이브러리의 compressBound를 사용합니다.
(Bug #32922688, Bug #33117410, Bug #33275424)

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

Keyring 관련 사항

keyring_hashicorp 플러그인 설정 문제에 대한 진단 기능이 개선되었습니다. (Bug #32075854)

Optimizer 관련 사항

EXPLAIN FORMAT=TREE는 이제 range optimizer가 생성한 스캔에 대해 이전에 표시되던 것보다 더 정확한 정보를 표시합니다. 특히 서브 이터레이터가 이제 명시적으로 표시되며, EXPLAIN ANALYZE로 올바르게 시간이 측정됩니다. 인덱스 범위 스캔은 이제 실제로 스캔되는 범위를 표시합니다. 출력의 설명도 이전보다 더 사용자 친화적입니다. 예를 들어 DISTINCT를 사용하는 쿼리에 대해 표시되던 index_for_group_by는 index skip scan for deduplication으로 대체됩니다.

또한 범위 교차 스캔에 대한 읽기의 로우 수 추정에서 부정확성을 일으키던 반올림 오류가 수정되었으며, 인덱스 범위 스캔에 대한 optimizer trace는 이제 InnoDB 프라이머리 키의 암시적 키 부분이 사용될 때 이를 올바르게 표시합니다. (Bug #33037007, Bug #33062448)
EXISTS를 세미조인으로 변환할 때, 그리고 쿼리에 뷰 참조가 포함되어 있을 때, 쿼리가 올바르게 처리되지 않았습니다. (Bug #32813550)

참조: 이 문제는 다음의 회귀입니다: Bug #30671329.
lateral 파생 테이블의 경우, 캐시 invalidator 생성이 지연되면 테이블 구체화가 invalidator 없이 방출되었으며, 이로 인해 실행 중 재구체화가 발생하지 못하고 잘못된 결과가 발생했습니다.

보류 중인 캐시 invalidator는 lateral 테이블의 인덱스가 고려 중인 테이블 목록의 마지막 테이블 인덱스보다 작은 경우에만 방출되었습니다. 보류 중인 invalidator의 테이블 인덱스가 조인 슬라이스의 마지막 테이블과 같으면 캐시 invalidator가 건너뛰어졌고 구체화가 invalidator 없이 방출되었습니다.

현재 조인 슬라이스의 테이블 목록에서 보류 중인 invalidator의 테이블 인덱스가 마지막 테이블의 인덱스보다 작거나 같은 경우 보류 중인 캐시 invalidator를 생성하여 이 문제를 수정합니다. (Bug #32407774)

Performance Schema 관련 사항

모니터링과 문제 해결을 지원하기 위해, 이제 Performance Schema 인스트루먼테이션이 인스트루먼트된 스레드의 이름을 운영 체제로 내보내는 데 사용됩니다. 이를 통해 디버거 및 Unix ps 명령과 같이 스레드 이름을 표시하는 유틸리티가 “mysqld”가 아니라 구별되는 mysqld 스레드 이름을 표시할 수 있습니다. 이 기능은 Linux, macOS 및 Windows에서만 지원됩니다. 자세한 내용은 The setup_instruments Table을 참조하십시오. (WL #14587)

Pluggable Authentication 관련 사항

Microsoft Windows: Linux에서 실행되는 MySQL 서버 및 클라이언트 호스트를 위해 MySQL 8.0.26에서 추가된 Kerberos 인증 방식이 이제 Windows의 클라이언트 측에서 지원됩니다. 이를 통해 Windows에서 실행되는 MySQL 클라이언트 애플리케이션은 Kerberos를 사용하여 인증하는 Linux 서버 호스트의 MySQL 계정에 연결할 수 있습니다. 자세한 내용은 Kerberos Pluggable Authentication을 참조하십시오. (WL #14605)

보안 관련 사항

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

서버 관리

다음 시스템 변수의 세션 값을 설정하는 작업은 이제 제한된 작업이며, 세션 사용자는 제한된 세션 변수를 설정하기에 충분한 권한을 가져야 합니다:
제한된 세션 변수를 설정하는 데 필요한 권한에 대한 정보는 System Variable Privileges를 참조하십시오. (WL #14695)

공간 데이터 지원

ST_SymDifference() 및 ST_Intersection() 함수는 이제 기하 인수가 지리 공간 참조 시스템(SRS)을 가지도록 허용합니다. 이전에는 ST_SymDifference() 및 ST_Intersection()가 데카르트 SRS의 기하 인수만 지원했습니다. 공간 연산자 함수를 참조하십시오. (WL #10996, WL #14273)

추가되거나 변경된 기능

중요한 변경 사항; Group Replication: group_replication_components_stop_timeout 시스템 변수는 Group Replication이 종료되는 동안 각 모듈이 진행 중인 프로세스를 완료하기를 기다리는 시간을 지정합니다. 컴포넌트 시간 제한은 STOP GROUP_REPLICATION 문이 실행된 후 적용되며, 이는 서버 재시작 또는 auto-rejoin 중에 자동으로 발생합니다. 이 시간 제한은 Group Replication 컴포넌트를 정상적으로 중지할 수 없는 상황을 해결하는 데 사용되며, 멤버가 오류 상태에 있는 동안 그룹에서 추방되거나, MySQL Enterprise Backup과 같은 프로세스가 멤버의 테이블에 대한 전역 잠금을 보유하는 동안 이러한 상황이 발생할 수 있습니다. 이러한 상황에서는 멤버가 applier 스레드를 중지하거나 재참여를 위한 distributed recovery 프로세스를 완료할 수 없습니다. STOP GROUP_REPLICATION 문은 상황이 해결되거나(예: 잠금이 해제됨), 컴포넌트 시간 제한이 만료되어 모듈이 상태와 관계없이 종료될 때까지 완료되지 않습니다.

이전에는 시간 제한 값의 기본값이 31536000초(365일)였으며, 이는 방금 설명한 것과 같은 상황에서 도움이 되지 않았습니다. 새 기본값은 300초이므로, 해당 시간 전에 상황이 해결되지 않으면 Group Replication 컴포넌트가 5분 후 중지되어 멤버를 재시작하고 재참여할 수 있습니다. (WL #14245)

참조: 다음도 참조하십시오: Bug #31460690, Bug #31648211, Bug #32309647.
Replication: 복제 서버에서 GTID 기반 복제를 사용하는 경우, 복제 applier 및 receiver 스레드는 대체 방식인 바이너리 로그 파일 위치 기반 복제에 사용되는 것처럼 바이너리 로그 파일 이름과 파일 위치를 계속 추적하며 이에 대한 일부 의존성을 가집니다. CHANGE REPLICATION SOURCE TO 문을 위한 새 옵션인 GTID_ONLY는 복제 메타데이터 저장소에서 파일 이름과 파일 위치의 영속화를 제거합니다. 이 설정이 적용된 복제 채널의 경우 메모리 내 파일 위치는 계속 추적되며, 파일 위치는 오류 메시지와 SHOW REPLICA STATUS 문 같은 인터페이스를 통해 디버깅 목적으로 계속 관찰할 수 있습니다(오래된 경우 유효하지 않은 것으로 표시됩니다). 그러나 GTID 기반 복제가 실제로 이를 필요로 하지 않는 상황에서는 파일 위치를 영속화하고 확인하는 데 필요한 쓰기와 읽기가 회피되며, 여기에는 트랜잭션 큐잉 및 적용 프로세스가 포함됩니다. GTID_ONLY 설정은 또한 복제 메타데이터가 덜 자주 flush됨을 의미합니다.

GTID_ONLY 옵션은 비동기 복제 채널에 대해 기본적으로 비활성화되지만, 그룹 복제 채널에 대해서는 기본적으로 활성화되며, 해당 채널에서는 비활성화할 수 없습니다. 복제 채널에 대해 GTID_ONLY = 1을 설정하려면 서버에서 GTID가 사용 중이어야 하며(gtid_mode = ON), 소스에서 로우 기반 바이너리 로깅이 사용 중이어야 합니다(문 기반 복제는 지원되지 않습니다). 복제 채널에 대해 CHANGE REPLICATION SOURCE TO 옵션 REQUIRE_ROW_FORMAT 및 SOURCE_AUTO_POSITION이 각각 1로 설정되어야 합니다. GTID_ONLY가 1로 설정된 경우, 해당 시스템 변수가 서버에 대해 0으로 설정되어 있으면 복제본은 replica_parallel_workers=1을 사용하므로, 기술적으로 항상 멀티스레드 applier입니다. 이는 멀티스레드 applier가 다시 적용해야 하는 트랜잭션의 시작 위치를 찾기 위해 복제 메타데이터 저장소가 아니라 저장된 위치를 사용하기 때문입니다.

이 문제와 관련된 기여를 제공해 준 Facebook에 감사드립니다. (Bug #94360, Bug #29364334, WL #7491)
복제: 이제 레플리카 서버에서 멀티스레딩이 기본적으로 활성화됩니다. 멀티스레드 applier에는 트랜잭션을 병렬로 실행하는 여러 applier 스레드가 있습니다. 이 동작은 소스와 레플리카 사이에 일시적인 차이를 유발할 수 있는 원치 않는 복제 지연의 많은 경우를 피할 수 있습니다.

다음 기본 서버 설정은 멀티스레딩 동작을 생성하는 데 사용됩니다:
- replica_parallel_workers=4. 이 설정은 멀티스레딩을 활성화하고 레플리카에 네 개의 applier 스레드와 이를 관리하는 coordinator 스레드를 생성합니다. 여러 복제 채널을 사용하는 경우 각 채널에는 이 수의 스레드가 있습니다. 네 개의 applier 스레드는 기본 수준의 병렬성을 제공하며, 설정을 변경하여 최대 1024개의 applier 스레드를 지정할 수 있습니다.
- replica_preserve_commit_order=1. 이 설정은 트랜잭션이 레플리카의 릴레이 로그에 나타나는 것과 동일한 순서로 레플리카에서 외부에 공개되도록 보장하므로, 레플리카는 마스터에 없었던 상태로 절대 진입하지 않으며 릴레이 로그에서 실행된 트랜잭션 시퀀스에 공백이 없습니다.
- replica_parallel_type=LOGICAL_CLOCK. 이 설정은 복제 소스 서버에서 동일한 바이너리 로그 그룹 커밋의 일부인 트랜잭션이 레플리카에서 병렬로 적용되도록 지정합니다. replica_preserve_commit_order=1이 설정된 경우 필요합니다.
새 기본값을 재정의하고 레플리카 서버에서 멀티스레딩을 비활성화하려면 replica_parallel_workers=0을 지정하십시오. 이 설정은 병렬 실행을 비활성화하고 레플리카에 단일 applier 스레드를 제공하며 coordinator 스레드는 제공하지 않습니다. 이 설정을 적용하면 replica_parallel_type 및 replica_preserve_commit_order 옵션은 효과가 없으며 무시됩니다. (WL #10475)
Group Replication: MySQL 복제를 위한 비동기 연결 장애 조치 메커니즘은 이제 관리형 복제 그룹의 일부인 레플리카가 현재 수신자(그룹의 프라이머리)에 장애가 발생하는 경우 송신자에 자동으로 다시 연결할 수 있도록 합니다. 새 기능은 단일 프라이머리 모드로 설정된 그룹에서 Group Replication과 함께 동작하며, 여기서 그룹의 프라이머리는 SOURCE_CONNECTION_AUTO_FAILOVER가 ON으로 설정된 복제 채널을 가진 레플리카입니다. 이 기능은 이러한 상황의 그룹에서 기본적으로 작동하지만, group_replication_disable_member_action() 함수를 사용하여 새 멤버 액션 mysql_start_failover_channels_if_primary를 비활성화함으로써 그룹에 대해 이 기능을 비활성화할 수 있습니다. 이 기능은 일부 멤버를 일시적으로 사용할 수 없는 경우에도 송신자 그룹과 수신자 그룹이 서로 동기화된 상태를 유지하도록 설계되었습니다. 또한 수신자 그룹을 관리형 그룹의 일부가 아닌 하나 이상의 송신자와 동기화합니다. 복제 그룹의 일부가 아닌 레플리카는 이 기능을 사용할 수 없습니다.

이 기능을 설정하려면 복제 채널과 채널에 대한 복제 사용자 계정 및 비밀번호가 복제 그룹의 모든 멤버 서버와 새로 참여하는 모든 멤버에 설정되어 있어야 합니다. CHANGE REPLICATION SOURCE TO 문을 사용하여 이를 수행할 수 있으며, 새 서버가 MySQL의 clone 기능을 사용하여 프로비저닝되는 경우에는 이 모든 작업이 자동으로 수행됩니다. 채널의 SOURCE_CONNECTION_AUTO_FAILOVER 설정은 멤버가 참여할 때 프라이머리에서 그룹 멤버로 브로드캐스트되며, 이 설정이 변경되는 경우에도 브로드캐스트됩니다. 소스 목록은 멤버가 참여하거나 소스 목록이 업데이트될 때 모든 멤버로 브로드캐스트됩니다. 프라이머리가 오프라인 상태가 되거나 오류 상태로 전환되면, 그룹에 대해 선택된 새 프라이머리는 소스 목록과 채널 설정을 이미 갖추고 있으며, 소스와 대체 비동기 복제 연결을 설정합니다.

관리자가 비동기 연결 장애 조치 메커니즘과 관련된 모든 설정을 제거할 수 있도록 새 함수 asynchronous_connection_failover_reset()도 제공됩니다. 관리형 그룹에서 더 이상 사용되지 않는 서버를 정리하려면 이 함수를 사용하십시오. (WL #14020)
Group Replication: Group Replication의 그룹 통신 엔진(XCom, Paxos 변형)은 기본적으로 그룹의 모든 멤버를 리더로 사용합니다. Group Replication 통신 프로토콜 버전이 8.0.27 이상으로 설정된 경우, 이제 그룹이 single-primary 모드일 때 그룹 통신 엔진은 합의를 구동하기 위해 단일 리더를 사용할 수 있습니다. 단일 합의 리더로 동작하면 single-primary 모드에서 성능과 복원력이 향상되며, 특히 그룹의 보조 멤버 중 일부에 현재 연결할 수 없는 경우에 그렇습니다.

단일 합의 리더는 그룹의 프라이머리와 같은 위치에 있으며, 새 프라이머리가 선출되면 변경됩니다. Performance Schema 테이블 replication_group_communication_information은 선호되는 합의 리더와 실제 합의 리더, 또는 모든 멤버가 리더로 사용되는 경우 리더들, 통신 프로토콜 버전, 쓰기 동시성을 보여줍니다.

새 동작을 활성화하려면 시스템 변수 group_replication_paxos_single_leader를 ON으로 설정하십시오(기본값은 OFF입니다). Group Replication이 multi-primary 모드에서 실행 중이거나, 이전 통신 프로토콜 버전을 사용하거나, group_replication_paxos_single_leader가 OFF로 설정된 경우, 그룹 통신 엔진은 그룹의 모든 멤버를 리더로 사용하여 동작합니다.

복제 그룹의 멤버를 새 MySQL Server 릴리스로 수동 업그레이드할 때, 그룹의 통신 프로토콜 버전은 이에 맞게 자동으로 업그레이드되지 않는다는 점에 유의하십시오. 이전 릴리스의 멤버 지원이 더 이상 필요하지 않은 경우, group_replication_set_communication_protocol() 함수를 사용하여 통신 프로토콜 버전을 멤버를 업그레이드한 새 MySQL Server 버전으로 설정할 수 있습니다. MySQL InnoDB Cluster는 해당 함수를 사용하여 생성된 복제 그룹에 대해 통신 프로토콜 버전을 자동으로 관리합니다. (WL #9149)
Group Replication: 이전 릴리스에서 Group Replication은 TLS/SSL 및 들어오는 Group Communication System (GCS) 연결에 대한 허용 목록 사용을 포함한 자체 보안 프로토콜 구현을 사용하여 멤버 간 그룹 통신 연결과 분산 복구 연결을 보호했습니다. 이제 복제 그룹은 Group Replication 구현 대신 MySQL Server 자체의 연결 보안을 사용할 수 있습니다. MySQL 프로토콜을 사용한다는 것은 허용 목록 대신 그룹에 대한 접근 권한을 부여하거나 취소하기 위해 표준 사용자 인증 방법을 사용할 수 있으며, 서버 프로토콜의 최신 기능을 릴리스 시 항상 사용할 수 있음을 의미합니다. MySQL 통신 스택을 사용할 때 Group Replication에 대해 네트워크 네임스페이스가 지원됩니다.

Group Replication 구현 대신 MySQL Server의 연결 보안 관리 구현을 사용하려면 새 시스템 변수 group_replication_communication_stack을 MYSQL로 설정하십시오. 또한 각 그룹 멤버에 대해 group_replication_local_address로 설정된 네트워크 주소는 bind_address에 지정된 대로 MySQL Server가 수신 대기 중인 IP 주소 및 포트 중 하나로 변경되어야 합니다. 네트워크 네임스페이스를 사용하는 경우, 이는 group_replication_recovery 채널에서 CHANGE REPLICATION SOURCE TO 문을 사용하여 설정해야 합니다.

인증은 CHANGE REPLICATION SOURCE TO를 사용하여 설정된 것처럼 Group Replication이 분산 복구에 사용하는 기존 복제 사용자 계정을 사용하여 수행되며, 이 사용자에게 새 GROUP_REPLICATION_STREAM 권한을 부여해야 합니다. 연결에 대한 TLS/SSL 설정은 분산 복구를 보호하기 위한 Group Replication의 기존 설정과, 그룹 통신에 대해 TLS/ SSL이 활성화 또는 비활성화되는지를 지정하는 group_replication_ssl_mode 시스템 변수에서 가져옵니다. 이러한 설정이 아직 적용되어 있지 않은 경우 설정해야 합니다. 통신 문제를 방지하려면 이러한 모든 설정이 모든 그룹 멤버에서 동일해야 합니다.

이 작업의 일부로, performance_schema_max_cond_classes 시스템 변수의 기본값이 100에서 150으로 증가했습니다.

자세한 내용은 Group Replication Requirements For The MySQL Communication Stack을 참조하십시오. (WL #9852)
옵션 파일에서 include 또는 includedir 지시문을 처리하는 동안 문제가 발생하는 프로그램은 이제 오류의 원인에 대해 더 많은 정보를 제공하는 오류 메시지를 생성합니다. (Bug #32798288, Bug #103397)
thread_stack 시스템 변수의 기본값이 지원되는 모든 플랫폼에서 1048576으로 증가했습니다. (Bug #103912, Bug #32965326)

참조: 다음도 참조하십시오: Bug #32934187.
이제 MySQL Server Docker 컨테이너를 시작하는 동안 서버 옵션 --default-time-zone을 사용하여 서버의 기본 시간대를 설정할 수 있습니다. 이전에는 이 옵션을 사용하면 컨테이너 시작에 실패했습니다. (WL #14703)
온라인 DDL 작업에서는 일반적으로 스토리지가 병목입니다. 이 문제를 해결하기 위해 CPU 사용률과 인덱스 빌드가 개선되었습니다. 이제 인덱스를 순차적으로 빌드하는 대신 동시에 빌드할 수 있습니다. 또한 사용자가 설정한 메모리 설정 한도를 준수하도록 메모리 관리가 강화되었습니다. Configuring Parallel Threads for Online DDL Operations를 참조하십시오.

새로운 innodb_ddl_threads 변수는 인덱스 생성의 정렬 및 빌드 단계에 대한 병렬 스레드의 최대 수를 정의합니다.

새로운 innodb_ddl_buffer_size 변수는 DDL 작업의 최대 버퍼 크기를 정의합니다. 기본 설정은 1048576바이트(약 1MB)입니다. 버퍼 크기 한도를 정의하면 보조 인덱스를 생성하거나 다시 빌드하는 온라인 DDL 작업에서 발생할 수 있는 메모리 부족 오류를 방지할 수 있습니다. Online DDL Memory Management를 참조하십시오. (WL #14283)
이제 clone 플러그인은 복제 작업이 진행 중인 동안 donor MySQL Server 인스턴스에서 동시 DDL 작업을 허용합니다. 이전에는 복제 작업 중 백업 락이 유지되어 donor에서 동시 DDL이 방지되었습니다. clone 작업 중 donor에서 동시 DDL을 차단하는 이전 동작으로 되돌리려면 clone_block_ddl 변수를 활성화하십시오. Cloning and Concurrent DDL을 참조하십시오. (WL #9683)
이제 internal_tmp_mem_storage_engine 변수에 세션 값을 설정하려면 SESSION_VARIABLES_ADMIN 또는 SYSTEM_VARIABLES_ADMIN 권한이 필요합니다. (WL #14728)

수정된 버그

호환되지 않는 변경: 뷰에 대한 모든 SELECT 문에서 쿼리 다이제스트는 뷰 정의를 기반으로 했습니다. 그 결과 서로 다른 쿼리가 동일한 다이제스트를 가지며 Performance Schema 테이블 events_statements_summary_by_digest에서 함께 집계되었으므로, 해당 테이블의 통계를 서로 다른 SELECT 문을 구분하는 데 사용할 수 없었습니다.

이제 뷰에 대한 각 SELECT 문의 쿼리 다이제스트는 뷰 정의가 아니라 SELECT를 기반으로 합니다. 이를 통해 events_statements_summary_by_digest 테이블에서 서로 다른 SELECT 문을 구분할 수 있습니다. 그러나 쿼리 다이제스트를 사용하는 도구는 이 변경을 고려하기 위해 일부 조정이 필요할 수 있습니다. 예를 들어 MySQL Enterprise Firewall 및 query rewrite 플러그인은 쿼리 다이제스트에 의존하며, 뷰와 연결된 기존 규칙은 업데이트해야 할 수 있습니다. (Bug #27540213, Bug #89559, Bug #31761802)
중요한 변경: EXPLAIN FORMAT=TREE는 이제 인덱스 스캔이 커버링 인덱스를 사용하는지 여부와, 따라서 테이블/클러스터형 인덱스에서 다른 컬럼을 조회할 필요가 없는지 여부를 표시합니다. 예를 들어 idx1이 커버링 인덱스인 경우, 이전 출력 Index scan on t1 using idx1은 이제 Covering index scan on t1 using idx1로 표시됩니다. 이전에는 이 정보가 FORMAT=TRADITIONAL 및 FORMAT=JSON에 대해서만 표시되었습니다.

이 수정은 또한 이 변경 사항에 맞추기 위해 전체 텍스트 검색에 사용되는 표현을 개선합니다. 예를 들어, 이전 출력 Indexed full text search on t1(커버링 및 비커버링 경우 모두에서 동일했음)은 이제 커버링 인덱스가 없을 때 Full-text index search on t1이 되고, 커버링 인덱스가 사용될 때 Full-text covering index search on t1이 됩니다. (Bug #32825235)
InnoDB: innodb_open_files 제한이 일시적으로 초과되었을 때 과도한 수의 관련 사항이 오류 로그에 기록되었습니다. (Bug #33343690)
InnoDB: in-place DDL 작업이 수정된 모든 페이지를 플러시하지 못했습니다. (Bug #33290335, Bug #33238133)
InnoDB: 병렬 스캔이 서브파티셔닝된 InnoDB 테이블에서 MySQL HeatWave로 데이터를 로드할 때 잘못된 파티션 ID를 반환했습니다. (Bug #33276021)
InnoDB: InnoDB 소스의 사용되지 않는 os_event::event_iter 필드가 os_event 구조체의 메모리 사용을 줄이기 위해 제거되었습니다.

기여해 주신 Facebook에 감사드립니다. (Bug #33252468)
InnoDB: srv_purge_thread 및 srv_worker_thread 스레드가 performance_schema.threads 테이블에 중복되어 있었습니다.

기여해 주신 Kaige Ye에게 감사드립니다. (Bug #33209066, Bug #104575)
InnoDB: 활성 트랜잭션에서 사용 중인 undo 테이블스페이스를 잘라내면 어설션 실패가 발생했습니다. 해당 트랜잭션이 조기에 완료된 것으로 표시되어 잘라내기 작업이 허용되었습니다. (Bug #33162828)
InnoDB: 기본 키를 수정하는 동시 DML이 있는 파티셔닝된 테이블에서 MySQL HeatWave로 데이터를 로드할 때, 로드 콜백에서 보고된 파티션 ID가 일부 레코드에 대해 올바르지 않은 것으로 확인되었습니다. (Bug #33139692)
InnoDB: InnoDB 소스의 MY_ATTRIBUTE((noreturn)) 및 MY_ATTRIBUTE((unused)) 인스턴스가 C++17 [[noreturn]] 및 [[maybe_unused]] 속성으로 대체되었습니다. (Bug #33112971)
InnoDB: 각 버퍼 풀 블록에는 block->lock_hash_val 필드가 포함됩니다. 이 값의 캐시는 버퍼와 잠금 시스템의 불필요한 결합 및 불필요한 메모리 사용을 초래하므로 필요하지 않은 것으로 판단되었습니다. (Bug #33072415)
InnoDB: 로우 ID로 정렬된 검색과 함께 인덱스 병합을 수행한 쿼리에서 assertion failure가 발생했습니다. 인덱스 병합을 위해 설정된 레코드 버퍼는 스캔된 테이블에 BLOB 컴포넌트를 포함하는 프라이머리 키가 있었기 때문에 사용할 수 없었습니다. 레코드 외부에 저장되는 BLOB를 읽는 데에는 레코드 버퍼를 사용할 수 없습니다. 프라이머리 키 컬럼이 아직 읽기 집합에 없었기 때문에, 레코드 버퍼가 설정될 때 BLOB 프라이머리 키가 감지되지 않았습니다. 로우 ID로 정렬된 검색은 필요할 때 나중 단계에서 프라이머리 키를 임시로 추가합니다. 이 문제를 해결하기 위해, 프라이머리 키에 BLOB 컴포넌트가 있는 경우 로우 정렬 검색에 대해 더 이상 레코드 버퍼를 요청하지 않습니다. (Bug #33067554)
InnoDB: 부모 테이블에서 로우를 삭제하거나 업데이트하면 자식 테이블에서 virtual 컬럼 값을 NULL로 설정하는 연쇄 SET NULL 작업이 시작되었습니다. virtual 컬럼 값은 베이스 컬럼 값에서 파생되어야 했습니다.

기여해 주신 Tencent의 Yin Peng에게 감사드립니다. (Bug #33053297)
InnoDB: 디스크 용량 한계에 가까워진 시스템에서, 파일 확장 redo log 레코드(MLOG_FILE_EXTEND) 적용을 포함하는 InnoDB 복구 작업이 실패를 일으킬 수 있었습니다. (Bug #33002492)
InnoDB: 동일한 레코드에 부여된 충돌하는 명시적 잠금으로 인해 assertion failure가 발생했습니다. (Bug #33000142)
InnoDB: purge 배치 끝에서 LOB의 첫 번째 페이지를 해제할 때 assertion 실패가 발생했습니다. 이 실패는 유효하지 않은 루트 페이지 번호 때문이었습니다. (Bug #32958624)
InnoDB: 실패 보고 및 해결을 용이하게 하기 위해, InnoDB 소스의 ib::fatal() 함수가 호출자의 위치를 포함하도록 개정되었습니다. (Bug #32957311)
InnoDB: clone 수신자 서버에서 복구가 다음 오류와 함께 실패했습니다: Error reading encryption for innodb_undo_007. clone 작업의 페이지 복사 단계 중에 생성된 암호화된 공간에 암호화 키가 기록되지 않았습니다. (Bug #32950216)
InnoDB: 원치 않는 경고 메시지 생성을 방지하기 위해, InnoDB 소스의 fil_space_acquire() 함수가 가능한 경우 fil_space_acquire_silent() 함수로 대체되었습니다. 두 함수 모두 백그라운드 스레드가 테이블스페이스를 획득하는 데 사용됩니다. (Bug #32944543)
InnoDB: InnoDB CRC32 체크섬 알고리즘 구현이 이제 ARM 및 x86/x64 아키텍처에서 사용하도록 최적화되었습니다. (Bug #32887066)
InnoDB: 수천 개의 테이블이 있는 인스턴스에서 시작 시 오류 로깅 하위 시스템의 대량 트래픽으로 인해 과도한 시간이 소요되었습니다. (Bug #32846656)
InnoDB: INFORMATION_SCHEMA.FILES 뷰가 임시 테이블스페이스 파일의 현재 경로를 표시하지 않았으며, 표시된 파일 이름이 innodb_temp_data_file_path 변수에 정의된 이름과 달랐습니다. (Bug #32840635, Bug #103553)
InnoDB: Windows에서 fil_shard 뮤텍스를 획득하려고 시도하는 동안 shared write lock 없이 파일을 열린 상태로 유지하면, fil_shard 뮤텍스를 획득한 뒤 동일한 파일에 접근하려고 시도하던 다른 스레드와 데드락이 발생했습니다. (Bug #32808809)
InnoDB: 실행 중인 다른 MySQL Server 인스턴스와 동일한 InnoDB 데이터 파일을 사용하여 MySQL Server 인스턴스를 시작하면 초기화 실패가 발생했습니다. (Bug #32777654, Bug #103338)
InnoDB: InnoDB 복구 프로세스가 복구 중인 데이터에 페이지 압축이 적용되었음을 인식하지 못하여, redo log 적용 단계 중 테이블스페이스 데이터 파일 크기가 증가했으며, 이로 인해 디스크가 가득 찬 상태에 가까워지는 시스템에서 복구 실패가 발생할 수 있었습니다. (Bug #32771259)
InnoDB: 파일 세그먼트 inode의 필드가 추적하는 사용된 페이지 수와 비교하기 위해, 가득 차지 않은 파일 세그먼트 목록을 순회하여 사용된 페이지 수를 계산하던 assert가 간헐적으로 실패했습니다. (Bug #31685095)
InnoDB: 온라인 DDL 작업 중 오류가 발생한 후 서버가 재시작되었을 때 트랜잭션 롤백에 실패했습니다. 커밋되지 않은 트랜잭션에 대해 테이블 잠금을 복원할 수 없었고, 영향을 받은 테이블에 대한 데이터 딕셔너리 테이블 객체를 로드할 수 없었습니다.

기여해 주신 Shaohua Wang에게 감사드립니다. (Bug #31131530, Bug #99174)
InnoDB: 집계에 임시 테이블을 사용한 쿼리가 TempTable 스토리지 엔진에서 사용할 수 있는 메모리를 모두 소진하여, 업데이트 작업이 테이블이 가득 찼다는 오류와 함께 실패했습니다. (Bug #31117893, Bug #99100)
Replication: 복제 applier (SQL) 스레드가 스토리지 엔진에서 발생한 재시도 가능한 오류(예: 데드락 및 대기 시간 초과)를 키를 찾을 수 없다는 오류로 덮어써, 트랜잭션을 재시도하지 않고 복제가 중지되었습니다. 이러한 오류는 더 이상 덮어쓰이지 않습니다. (Bug #33107663)
Replication: Group Replication 분산 복구 프로세스가 조인하는 멤버를 donor와 동기화할 때, Performance Schema 테이블 replication_group_member_stats 테이블이 group_replication_applier 채널에서 큐에 대기 중인 현재 트랜잭션 수(COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 필드)로 업데이트되지 않았습니다. 이제 분산 복구 중 새 트랜잭션이 도착하는 동안 해당 수가 추적되지만, joiner가 분산 복구의 첫 번째 단계에서 수신한 트랜잭션을 인증할 때까지는 0으로 유지됩니다. (Bug #33067441)
복제: 멀티스레드 레플리카(replica_parallel_workers가 0보다 큰 값으로 설정된 레플리카)의 경우, replica_parallel_workers가 1로 설정되면 이제 replica_preserve_commit_order 설정이 무시됩니다. 적용자가 하나인 경우 트랜잭션은 항상 레플리카의 릴레이 로그와 같은 순서로 실행되고 커밋되며, 커밋 순서를 보존하는 프로세스를 무시하면 잠재적인 성능 저하를 피할 수 있습니다. (Bug #33048169)
복제: 시간대가 채워지지 않은 레플리카 MySQL Server 인스턴스가 레플리카에 알려지지 않은 시간대 값을 설정하는 구문을 복제하려고 시도하면 assertion이 발생했습니다. 이제 레플리카는 이 상황을 올바르게 처리합니다. (Bug #32986721)
복제: 자동 위치 지정을 위해 필요한 GTID가 제거되었을 때 MySQL 복제에서 발행하는 오류 메시지가 일부 상황에서 잘못 할당되거나 뒤섞일 수 있었습니다. (Bug #32965864)
Replication: 그룹 멤버가 종료되기 직전이나 종료 중에 프라이머리로 선출된 경우, 종료로 인해 선출이 실패했으므로 서버가 그룹을 떠나도록 시도하던 프라이머리 선출 프로세스를 기다리는 동안 종료 프로세스가 중단되었습니다. 이제 프라이머리 선출의 오류 처리 프로세스는 이를 고려하며, 멤버가 이미 그룹을 떠나는 중이면 더 이상 어떤 동작도 수행하지 않습니다. (Bug #32884709)
Replication: 쿼리 프로세스 중에 로우가 삭제된 경우 Performance Schema 테이블 replication_asynchronous_connection_failover를 쿼리하면 오류가 반환될 수 있었습니다. 이 상황에서는 이제 로우 수가 0으로 반환되며, 쿼리를 다시 시도할 수 있습니다. (Bug #32701593)
Replication: 일부 상황에서 연결 압축을 사용한 레플리카가 소스 서버에 대한 손실된 연결을 다시 설정할 수 없었습니다. 이 문제가 이제 수정되었습니다. (Bug #32494609)
Group Replication: Group Replication 자동 재참여 절차 중 그룹 멤버는 자신의 상태를 RECOVERING으로 설정합니다. 그룹 멤버가 재참여에 성공하지 못하면 상태를 ERROR로 변경해야 하지만, 그동안 뷰 변경이 발생한 경우 상태가 RECOVERING으로 남아 있을 수 있었습니다. 이제 자동 재참여 절차가 성공하지 못한 후에는 진행 중이거나 멈춘 뷰 변경이 있더라도 멤버 상태가 ERROR로 설정됩니다. (Bug #33276418)
Group Replication: 인증 정보의 가비지 컬렉션이 Group Replication Group Communication System (GCS) 스레드에서 백그라운드 스레드로 이동되어, 가비지 컬렉션이 진행 중인 동안 메시지 송수신이 차단되지 않습니다. (Bug #33190276)
Group Replication: group_replication_consistency가 BEFORE_ON_PRIMARY_FAILOVER인 경우, 프라이머리 페일오버 이벤트에서 새 프라이머리가 이전 프라이머리와 동일한 상태를 가질 때까지 클라이언트 연결이 보류됩니다. 일부 모니터링 및 관리 구문은 이 보류에서 제외되어, 페일오버 프로세스 중에 새 프라이머리를 검사할 수 있습니다.

이전에는 DO 구문이 이 보류에서 일괄적으로 제외되었지만, 이제는 테이블이나 로드 가능한 함수를 사용하지 않는 DO 구문만 제외됩니다. 이는 SELECT의 경우와 동일합니다. (Bug #33130768)
Group Replication: MySQL Server가 Group Replication이 중지 또는 재시작되는 동안 Group Replication과 관련된 Performance Schema 테이블에서 읽기를 잘못 허용했으며, 해당 데이터는 사용되어서는 안 되었습니다. 이제 서버는 쿼리를 실행하기 전에 Group Replication이 OFFLINE 상태인지 또는 초기화되지 않았는지 확인합니다. (Bug #33085494)
Group Replication: group_replication_consistency가 BEFORE_ON_PRIMARY_FAILOVER로 설정된 경우, 프라이머리 페일오버 이벤트에서 새 프라이머리가 이전 프라이머리와 동일한 상태를 가질 때까지 클라이언트 연결이 보류됩니다. 일부 모니터링 및 관리 명령문은 이 보류에서 제외되므로, 페일오버 프로세스 중에 새 프라이머리를 검사할 수 있습니다. 이전에는 SHOW 명령문이 보류에서 일괄적으로 제외되었지만(SHOW CREATE USER는 예외), 이제 데이터에 의존하지 않는(상태 또는 설정에만 의존하는) SHOW 명령문만 제외됩니다. 제외되는 SHOW 명령문의 전체 목록은 Configuring Transaction Consistency Guarantees를 참조하십시오. (Bug #33082509)
Group Replication: Group Replication 그룹의 프라이머리에서 CREATE USER와 같이 Access Control Lists (ACLs)를 참조하는 문이 실행되고, 이후 트랜잭션 커밋이 다른 그룹 멤버에 의해 확인되기 전에 멤버가 즉시 그룹에 조인하면 데드락이 발생할 수 있었습니다. 분산 복구 프로세스에는 ACL 문에 의해 잠긴 ACL 캐시에 대한 읽기 잠금이 필요합니다. 이 상황은 ACL 문이 타임아웃될 때까지 Group Replication의 Group Communication System (GCS) 스레드를 차단하여 프라이머리에 도달할 수 없게 만들고, 새 멤버가 조인하지 못하게 할 수도 있었습니다. 이제 분산 복구 프로세스에는 ACL 캐시 잠금이 더 이상 필요하지 않지만, 설명된 상황의 잠금은 뷰 변경이 완료되고 ACL 문이 커밋된 후에만 해제됩니다. 따라서 MySQL 통신 스택을 사용하는 Group Replication에서의 멤버 조인을 포함하여 ACL 캐시 잠금이 필요한 모든 새 연결 또는 문은 이를 기다리거나 실패한 후 재시도해야 합니다. (Bug #33025231)

the sentence count is accurate. For terms, I’ll translate "thread" to "스레드" and perhaps "applier module" to "적용자 모듈," which could relate to the Group Replication applier module. "Group transactions" will be "그룹 트랜잭션," and "messages" will translate to 목: Bug..."Translating technical terms
Group Replication: Group Replication 적용자 모듈을 실행하는 스레드가 중지되면, 그룹 트랜잭션과 메시지를 교환할 수 없기 때문에 그룹이 제대로 작동할 수 없습니다. 이전에는 이 상황의 멤버가 ONLINE 상태로 남아 내부 오류를 무시했습니다. 이제 스레드가 중지되면 멤버가 ERROR 상태로 변경되고, group_replication_exit_state_action에 지정된 작업을 수행합니다. (Bug #32934479)
Group Replication: MySQL 8.0.22 이상에서 복제 소스 서버는 서버 재시작 후 MEMORY 테이블이 처음 사용될 때 복제본에 해당 테이블을 비우도록 알리기 위해 TRUNCATE TABLE 문을 바이너리 로그에 기록합니다. 이전에는 해당 문이 기록된 스레드가 글로벌 스레드 매니저에 등록되지 않아 Group Replication이 이를 확인할 수 없었습니다. 이제 이 문제가 수정되었습니다. (Bug #32355801)
JSON: MySQL 8.0.23에서 적용된 JSON 함수 오류 처리 개선에 추가 개선 사항을 적용했습니다. (Bug #32864910)

참조: 다음도 참조하십시오: Bug #31856260.
JSON: JSON_TABLE()는 MySQL에서 컬럼 이름이 case-insensitive임에도 불구하고, 이름이 대소문자만 다른 경우 중복 컬럼 이름을 허용했습니다.

이제 이 함수는 컬럼 이름을 case-insensitive 방식으로 비교합니다. (Bug #102824, Bug #32591074)
Ubuntu 21.10 패키지가 추가되었습니다. (Bug #33501583, Bug #105274)
EL6에서의 빌드와 같이 MySQL이 OpenSSL 1.0.1에 링크된 경우, MySQL 클라이언트 라이브러리가 메모리 누수에 영향을 줄 수 있었습니다. (Bug #33335046)
암시적으로 그룹화된 쿼리는 값이 인덱스에서 쉽게 검색될 수 있을 때 최적화 중에 집계를 계산하는 경우가 있습니다. 조건자가 NO PAD 콜레이션으로 선언된 컬럼을 참조할 때, 해당 조건자가 PAD SPACE 의미 체계를 사용하여 평가되어 잘못된 결과를 반환할 수 있었습니다. 이는 중요하지 않은 후행 공백을 검사하는 내부 함수가 모든 논바이너리 콜레이션이 PAD SPACE 의미 체계를 가진다고 가정했기 때문이며, 이는 MySQL 5.7에서는 참이었지만 기본 콜레이션(utf8mb4_0900_ai_ci)을 포함하여 NO PAD 의미 체계를 가진 많은 콜레이션이 추가된 MySQL 8.0에는 해당되지 않습니다.

이러한 경우 콜레이션의 패딩 속성을 명시적으로 검사하여 이 문제를 수정했습니다. (Bug #33282123)
full-text 인덱스 없이 정의된 테이블에서 실행된 MATCH() AGAINST() 절이 있는 공통 테이블 표현식을 포함한 쿼리가 어설션 실패를 발생시켰습니다. (Bug #33264864)
여러 Performance Schema 테이블에 기본 sql_mode 값인 NO_ZERO_IN_DATE 및 NO_ZERO_DATE와 충돌하는 기본 타임스탬프 값 0(영)이 포함되어 있었습니다.

예를 들어, 이러한 Performance Schema 테이블을 기반으로 새 테이블을 생성하려고 시도하면 다음과 유사한 오류가 발생했습니다: ERROR 1067 (42000): Invalid default value for 'FIRST_SEEN'

다음 테이블에서 기본 타임스탬프 값이 제거되었습니다:
- performance_schema.events_errors_summary_by_account_by_error
- performance_schema.events_errors_summary_by_host_by_error
- performance_schema.events_errors_summary_by_thread_by_error
- performance_schema.events_errors_summary_by_user_by_error
performance_schema.events_errors_summary_global_by_error
- performance_schema.events_statements_summary_by_digest
- performance_schema.host_cache
- performance_schema.replication_applier_filters
- performance_schema.replication_applier_global_filters
(Bug #33240123, Bug #104643)
NOTIFY_SOCKET 환경 변수에 대한 쓰기 실패로 인해 실패가 발생했습니다. 실패한 쓰기와 연결된 ER_SYSTEMD_NOTIFY_WRITE_FAILED 오류에는 두 개의 파라미터가 있지만, 오류 로깅 루틴에는 하나의 파라미터만 전달되었습니다. (Bug #33239183)
--ssl-fips-mode 옵션을 설정할 때 잘못 타입 캐스팅된 변수가 사용되었습니다. (Bug #33223230)
다음 스레드가 performance_schema.threads 테이블에 없었습니다:
- buf_resize_thread
- fts_optimize_thread
기여해 주신 Kaige Ye에게 감사드립니다.

기여해 주신 Kaige Ye에게 감사드립니다. (Bug #33214130, Bug #104582, Bug #33214136, Bug #104583)
내부 저장 함수에 대한 재귀 호출로 인해 예기치 않은 오류가 발생했습니다. (Bug #33198164)
내부 mysqld_list_fields() 함수가 JSON 테이블 함수를 평가하기 위해 생성된 임시 테이블을 제거하지 못했습니다. (Bug #33177686)
최소 TAR 패키지를 생성하는 코드가 패키지에 디버그 심볼을 추가했으며, 이로 인해 빌드 크기가 더 커졌습니다(대략 10배). 이제 디버그 심볼 빌드에는 DEB/RPM 컴파일러 플래그가 기본적으로 켜져 있고, 최소 크기 릴리스 빌드에는 기본적으로 꺼져 있습니다. (Bug #33151629, Bug #104402)
일부 다중 테이블 DELETE 문에서 메모리 누수가 발견되었습니다. (Bug #33151275)

참조: 다음도 참조하십시오: Bug #18684036.
서버 내부의 복사 함수에 대한 반환 값이 예상대로 처리되지 않았습니다. (Bug #33142669)

참조: 이 문제는 다음의 회귀입니다: Bug #31982292.
빈 범위 프레임이 항상 올바르게 처리되지는 않았습니다. (Bug #33142418)

참조: 이 문제는 다음의 회귀입니다: Bug #90300, Bug #27808099.
디버그 빌드에서 ALTER TABLE 문은 나중에 외래 키에서 참조되는 컬럼 중 하나와 같은 이름의 새 가상 컬럼을 추가하는 경우 오류를 발생시킬 수 있었습니다. 이 수정에서는 이제 이름이 중복되는 경우 가상 컬럼을 무시하고, 대신 기존의 비가상 컬럼 이름을 사용하여 조건을 검사합니다. (Bug #33114045)
저장 프로그램 명령의 실행이 오류가 없는 상태에서 시작되도록 보장하는 assert 조건이 루프 안의 CASE 문에 대해 제대로 작동하지 않았습니다. (Bug #33079184)
디버그 빌드에서 UPDATE HISTOGRAM 절을 사용하는 ANALYZE TABLE은 진단 영역을 성공적으로 지운 후 성공 값을 반환하는 대신 성공이 아닌 값을 호출자에게 반환할 수 있었습니다. (Bug #33079073)
mecab_charset 시스템 상태 변수는 이제 사용 중단된 utf8이 아니라 utf8mb4로 값을 보고합니다. (Bug #33078623)
디버그 빌드에서 MySQL Enterprise Encryption UDF가 NULL을 반환할 때 nullable 플래그를 설정하지 않았습니다. (Bug #33077931)
플랜 잠금이 적용 중일 때 range 옵티마이저가 호출되는 경우가 있었습니다. 이로 인해 문제가 발생했는데, range 옵티마이저는 자신을 호출할 수 있지만 플랜 잠금은 재귀를 허용하지 않기 때문입니다. (Bug #33076462)

참조: 이 문제는 다음의 회귀입니다: Bug #18684036.
저장 루틴 내부에서 사용될 때 CAST() 및 DEFAULT()이 항상 올바르게 처리되지는 않았습니다. (Bug #33075828)
평가 중 임시 문자열 버퍼를 사용하는 문자열 함수가 예기치 않은 종료로 이어질 수 있었습니다. (Bug #33073951)
호스트 이름을 IP 주소로 확인하지 못한 후 출력되는 오류 메시지에 의미 있는 errno 값이 포함되지 않았습니다. 이제 메시지에서 (0) 대신 EAI_NONAME을 나타내는 (-2)가 반환됩니다. (Bug #33064143)
CREATE TABLE t SELECT 1과 같은 명령문은 binlog_format 값이 ROW로 설정되고 sql_mode가 ANSI 모드인 경우, 바이너리 로그에 잘못 기록되는 InnoDB 테이블을 생성했습니다. 그 결과, 해당 명령문의 복제가 복제본에서 오류와 함께 실패했습니다. 이러한 바이너리 로그에 mysqlbinlog 유틸리티를 적용하는 경우에도 실패할 수 있었습니다.

Atomic CREATE...SELECT는 CREATE TABLE에 START TRANSACTION이라는 새 절을 추가하여 구현되었습니다. 그러나 이 절은 ANSI 모드가 활성화된 경우 추가되지 않았습니다. 이는 다시 트랜잭션 중간에 일반적인 암시적으로 커밋되는 CREATE TABLE이 실행되도록 했으며, 트랜잭션에 할당된 GTID가 있는 경우 GTID 모드에서 오류를 발생시켰습니다. 이 문제는 새 절에서 SQL 모드 의존성을 제거하여 수정되었습니다. (Bug #33064062, Bug #104153)
잘못된 형식의 ISO8601 타임스탬프가 포함된 로그 파일이 올바르게 처리되지 않았습니다. (Bug #33060440)
이전에 utf8을 참조하던 문자열 변환 경고가 이제 대신 utf8mb3를 참조합니다. (Bug #33059330)
Unix 플랫폼에서 소스로부터 MySQL을 빌드할 때, 이제 Boost 아카이브 다운로드에 .tar.gz 파일이 아니라 .bz2 파일이 사용됩니다. (Bug #33052171)
Enterprise Linux 8 및 Fedora의 경우, fprofile.cmake에서 REPRODUCIBLE_BUILD를 비활성화하여 debuginfo RPMS 패키지를 수정했습니다. (Bug #33037380)
rollup을 사용하는 쿼리에서, 표현식에 grouping 컬럼이 있기 때문에 해당 표현식을 nullable로 설정할 때 그 표현식 내의 모든 표현식을 nullable로 설정하지 못하고, 최상위 표현식에 대해서만 그렇게 했습니다. 이는 평가 중에 rollup에 의해 생성된 NULL이 항상 올바르게 전파되지는 않았음을 의미했습니다. 이를 수정하기 위해, 이제 쿼리가 rollup을 사용할 때 grouping 컬럼이 있는 모든 표현식을 nullable로 설정합니다. (Bug #33036184)
EXPLAIN을 실행하는 동안, 스트리밍 또는 materialization 노드를 통해 다른 쿼리 블록으로 넘어갈 때 이 노드가 실제 루트 노드가 아니라 루트로 계산되었습니다. (Bug #33030136)
sql/join_optimizer/cost_model.cc에서 double에서 int64로의 정의되지 않은 변환을 수정했습니다. (Bug #33024410)
내부 함수 find_in_group_list()는 ROLLUP 처리 중 모든 항목을 올바르게 일치시키지 못했습니다. GROUP BY 표현식에 캐스트를 추가하여 이 문제를 수정했습니다. (Bug #33022742, Bug #33123934)

참조: 이 문제는 다음의 회귀입니다: Bug #30969045.
MySQL 클라이언트 라이브러리에서 메모리 할당 성공 여부에 대한 테스트가 누락되어 클라이언트가 종료될 수 있었습니다. (Bug #33019026)
준비된 명령문에서 감사 로그 함수 호출이 오류를 발생시켰습니다. (Bug #33016004)
새 이름이 functional index에 사용되는 기존 숨겨진 컬럼의 이름과 충돌하지 않도록, !hidden! 접두사가 붙은 컬럼 이름을 추가하지 않도록 했습니다. 생성된 숨겨진 컬럼 이름은 이제 MD5()에서 생성한 이름을 지원하지 않는 환경으로 functional index 사용을 확장하는 다음의 새 형식을 가집니다:

!hidden!index_name!key_part_number!counter

생성된 이름의 counter 값은 해당 이름을 가진 컬럼이 테이블에 이미 존재하지 않는 한 0입니다. 이 경우 이름이 고유해질 때까지 값이 증가합니다. (Bug #32983024)
sql_help.cc에서 range optimizer에 대한 불필요한 하드 코딩된 의존성을 제거했습니다. (Bug #32976042)
윈도우 함수 실행 중 버퍼 공간 할당이 부족하여 assertion이 발생할 수 있었습니다. (Bug #32975889)
hash join 아래의 테이블 목록을 찾을 때 ZERO_ROWS 반복자 아래에도 숨겨져 있던 테이블을 고려하지 않았습니다. 이로 인해 NULL 로우 플래그가 올바르게 설정되지 않을 수 있었으며, weedout이 해당 로우 ID를 저장하려고 할 때도 문제가 발생했습니다. (Bug #32975168)
gen_dictionary(), gen_range(), gen_rnd_pan() 데이터 마스킹 함수는 각각 시간적으로 매우 가까운 간격으로 여러 번 실행될 경우 같은 값을 생성할 수 있었습니다. (Bug #32970772)
공통 테이블 표현식의 해석에 사용되는 임시 테이블의 생성 및 삭제와 서브쿼리 내에서 생성된 테이블 참조를 갖는 임시 테이블의 생성 및 삭제가 항상 올바르게 관리되지는 않았습니다. (Bug #32962511)
mysql 클라이언트에서 -–binary-as-hex 옵션이 활성화된 경우, 이제 빈 문자열은 NULL 대신 0x로 출력됩니다. (Bug #32961656, Bug #103906)
리졸버는 일반적으로 명령문에서 오류를 만나면 분석을 종료하고 빠져나갑니다. 중복 컬럼 분석의 경우 리졸버가 컬럼 목록의 끝까지 계속 진행하여, 진단 객체에 여러 오류 메시지를 추가할 수 있었습니다. (Bug #32960158)
스칼라 서브쿼리가 여러 로우를 반환할 때, 그 결과 오류가 항상 올바르게 처리되지는 않았습니다. (Bug #32956779)
생성 컬럼이 포함된 테이블을 생성한 후 서버 SQL 모드를 변경하면 오류 로그에 잘못된 메시지가 기록될 수 있었습니다. (Bug #32954466)
Windows에서 manifest 파일 읽기가 실패할 수 있었습니다. (Bug #32950322)
IN() 목록의 값 평가는 오류 발생 시 즉시 중단되지 않았으며, 이로 인해 assert 실패가 발생했습니다. 이러한 경우 오류가 발생하는 즉시 평가를 중단하도록 수정했습니다. (Bug #32942328)
널을 허용하지 않는 두 값을 문자열로 비교하는 평가 중 오류가 발생하면, 비교 연산자 메타데이터에 따르면 결과가 널을 허용하지 않는데도 비교 결과가 NULL로 설정되었습니다. 오류는 사용자에게 올바르게 반환되었지만, 디버그 모드에서 실행할 때 이 불일치로 인해 assertion이 발생했습니다.

소유자가 널을 허용하지 않는 경우 Arg_comparator가 해당 소유자를 NULL로 설정하지 않도록 하여 이 문제를 수정했습니다. (Bug #32942327)
업그레이드 작업 중 실행된 SQL 스크립트에서 참조된 설정되지 않은 변수가 실패를 유발했습니다. (Bug #32939819)
filesort 작업에서 부적절한 오류 전파로 인해 assertion이 발생할 수 있었습니다. (Bug #32932969)
내부 WalkAndReplace() 함수에서 set_cmp_func()의 오류가 올바르게 전파되지 않았습니다. (Bug #32918927, Bug #33007298)

References: 이 문제는 다음의 regression입니다: Bug #32548377.
채널 설정을 읽는 동안 RESET REPLICA ALL 문이 사용되면 데드락이 발생할 수 있었습니다. (Bug #32906709)
지속 변수 캐시에 접근할 때 발생할 수 있는 잠재적 경합 조건이 제거되었습니다. (Bug #32901419)
MySQL Optimizer가 수행하는 상수 전파가 일부 경우 nullable이 아닌 컬럼에 대한 참조를 nullable 표현식으로 대체할 수 있었습니다. 이 문제가 발생하면 대체된 컬럼 참조의 부모 항목이 때때로 잘못된 nullability를 가질 수 있었으며, 이로 인해 이후 실행 중 nullable이 아닌 항목이 예기치 않게 NULL을 반환할 때 assertion 실패가 발생했습니다.

nullable이 아닌 컬럼 참조가 nullable 표현식으로 대체되는 경우 상수 전파를 건너뛰도록 하여 이 문제를 수정했습니다. (Bug #32895824)

References: 이 문제는 다음의 regression입니다: Bug #32371039.
쿼리에서 제공된 컬럼 이름은 콜레이션 세부 사항에서 다를 수 있거나, 해당 이름이 쿼리에서 표현식 별칭으로 제공되었기 때문에 다를 수 있었으며, 그래도 딕셔너리의 컬럼 이름과 일치할 수 있었습니다. 쿼리 출력에는 딕셔너리의 컬럼 이름(예: AAA)이 아니라 쿼리에 지정된 컬럼 이름(예: aaa)이 포함되었습니다. (Bug #32892045)
서버 SQL 모드가 strict mode가 아닌 경우, 특정 문자열 함수는 결과가 결과 버퍼에 비해 너무 크다는 것을 나타내기 위해 NULL을 반환하며, 이로 인해 잘못 정렬된 출력과 같은 일관되지 않은 동작이 발생할 수 있었습니다. 또한 LAST_INSERT_ID() 및 CAST(... AS CHAR) 함수는 모든 경우에 null 허용 여부를 올바르게 유지하지 않았습니다. (Bug #32864958)
ORDER BY, 윈도우 함수 또는 뷰에 대한 참조의 일부로 추가된 숨겨진 항목이 암시적으로 그룹화된 쿼리에서 항상 올바르게 처리되지는 않았습니다. (Bug #32863279, Bug #33079592)
부정에 대한 타입 결정은 타입을 정수에서 십진수로 변환할 때 적절한 정밀도를 설정하지 않았습니다. 이는 인수와 동일한 정밀도를 할당하여 수정되었습니다. (Bug #32863037)

참조: 이 문제는 다음의 회귀입니다: Bug #31348202.
실패한 CREATE TABLE... SELECT 문에 대한 부적절한 오류 전파로 인해 롤백이 발생하지 않았습니다. (Bug #32855882)
서브쿼리에서 사용될 때, 둘 이상의 ROW()를 가진 VALUES가 항상 올바르게 처리되지는 않았습니다. (Bug #32851684)
wait timeout이 만료될 때 MySQL Server가 클라이언트 프로그램으로 보내는 오류 패킷(ER_CLIENT_INTERACTION_TIMEOUT)은 프로토콜 압축이 사용된 경우 패킷 헤더에서 0 대신 잘못된 시퀀스 번호 2를 사용했습니다. (Bug #32835205, Bug #103412)
전체 텍스트 인덱스가 있는 여러 테이블에 대한 동시 삽입 작업으로 인해 많은 수의 전체 텍스트 인덱스 동기화 요청이 발생했으며, 그 결과 메모리 부족 상태가 발생했습니다. (Bug #32831765, Bug #103523)
이전 문제에 대한 수정 사항은 이후 작업으로 인해 중복되었고 윈도우 함수에서 사용된 표현식에서 잘못된 결과를 초래했으므로 되돌려졌습니다. (Bug #32820802)

참조: 되돌려진 패치: Bug #26389508.
준비된 문에서 NULLIF() 결과 타입 결정이 올바르지 않을 수 있었습니다. (Bug #32816305, Bug #103458)
저장 루틴 내에서 뷰를 생성하고 삭제하는 작업이 항상 올바르게 처리되지는 않았습니다. (Bug #32807430)
이전 문제에 대한 수정에는 decimal 표현식의 정밀도와 스케일을 결정하는 방식에 대한 사소한 리팩터링이 포함되었습니다. 이후 TRUNCATE() 함수의 경우 정밀도가 0이 될 수 있으며, 이는 유효하지 않다는 점이 드러났습니다.

이 문제는 정밀도 0을 1로 처리하여 수정했습니다. (Bug #32802251)

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

레거시 이유로 table_path 내부에 Filter 및 Sort를 포함하는 복합 액세스 경로가 있을 수 있습니다. 분석을 쉽게 하고 형식을 더 좋게 하기 위해, 이들에 대한 EXPLAIN 출력을 Materialize 액세스 경로 앞으로 이동합니다.

여기서는 이 변경 전후에 실행한 EXPLAIN 문의 예를 보여줍니다:

# Table created as follows:
mysql> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected (0.02 sec)

mysql> CREATE TABLE t1 ( f1 INTEGER );
Query OK, 0 rows affected (0.03 sec)

# Previous to change:
mysql> EXPLAIN FORMAT=TREE
    ->   SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1
    ->   WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G
*************************** 1. row ***************************
EXPLAIN: -> Sort: alias1.f1
-> Filter: <nop>((alias1.f1 <= (select #3)))  (cost=2.62 rows=2) [other sub-iterators not shown]
    -> Table scan on alias1  (cost=2.62 rows=2)
        -> Materialize  (cost=0.35..0.35 rows=0)
            -> Limit/Offset: 2/1 row(s)  (cost=0.35 rows=0)
                -> Table scan on t1  (cost=0.35 rows=1)

다음 변경 사항:

mysql> EXPLAIN FORMAT=TREE -> SELECT * FROM ( SELECT * FROM t1 LIMIT 2 OFFSET 1 ) AS alias1 -> WHERE f1 <= ANY ( SELECT f1 FROM t1 ) ORDER BY f1\G *************************** 1. row *************************** EXPLAIN: -> Sort: alias1.f1 (cost=0.35..0.35 rows=0) -> Filter: ((alias1.f1 <= (select #3))) (cost=2.62 rows=2) -> Table scan on alias1 (cost=2.62 rows=2) -> Materialize (cost=0.35..0.35 rows=0) -> Limit/Offset: 2/1 row(s) (cost=0.35 rows=0) -> Table scan on t1 (cost=0.35 rows=1) -> Select #3 (subquery in condition; run only once) -> Aggregate: max(t1.f1) (cost=0.45 rows=1) -> Table scan on t1 (cost=0.35 rows=1)


이 변경 후 `table_path` 내에서 유효한 접근 경로는 `TABLE_SCAN`, `REF`, `REF_OR_NULL`, `EQ_REF`, `ALTERNATIVE`뿐입니다. (Bug #32788576, Bug #32915233)
- 상수 폴딩은 십진수 표현식을 평가할 때 항상 오류를 올바르게 처리하지는 않았습니다. (Bug #32785804)

- `Query_block::prepare_values()`의 호출 순서 불일치로 인해 `resolve_subquery()` 이후에 `setup_order()`가 호출되었으며, 이는 서브쿼리인 `VALUES` 절의 경우 `setup_order()`를 호출하기 전에 서브쿼리가 외부 쿼리 블록으로 병합될 수 있음을 의미하여, 일관되지 않은 데이터 구조와 오류로 이어졌습니다.

이 문제는 `setup_order()`를 더 일찍 수행하고, 컬럼을 찾을 수 없는 경우 해석을 중단하도록 하여 수정했습니다. (Bug #32783943)

참고: 이 문제는 Bug #31387510의 회귀입니다.
- Performance Schema 테이블 `variables.info`에서 시스템 변수 `skip_slave_start`는 전역 값이 실제로는 지속 변수 파일에서 로드되었을 때 잘못 `COMPILED`로 나열되었으므로, `PERSISTED`가 사용되었어야 했습니다. (Bug #32640588)
- 동시 MySQL 서버 부하가 있는 상태에서 [`INFORMATION_SCHEMA.PROCESSLIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-processlist-table.html) 뷰에 대한 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 쿼리가 실패를 발생시켰습니다. (Bug #32625376)

- 쿼리가 집계에 임시 테이블을 사용하는 경우, group by 항목은 임시 테이블의 고유 제약 조건으로 사용됩니다: 항목 값이 이미 존재하면 로우가 업데이트되고, 그렇지 않으면 새 로우가 임시 테이블에 삽입됩니다. 항목에 결과 필드 또는 참조 항목이 있으면, 결과가 임시 테이블에 존재하는지 확인하기 위해 한 번 평가되고, 존재하지 않는 경우 삽입할 로우를 구성하는 동안 다시 평가되어 두 번 평가되었습니다. group by 항목이 비결정적일 때, 존재 여부를 확인하는 데 사용된 결과 값이 삽입을 시도한 값과 달라졌고, 이로 인해 해당 값이 테이블에 이미 존재하는 경우 삽입이 거부되었습니다.

비결정적 항목의 해시를 고유 제약 조건으로 사용하여, 해시가 한 번만 평가되도록 하여 이 문제를 수정했습니다. (Bug #32552332)
- 테이블별 롤에 대한 권한 검사가 일부 컨텍스트에서 충분히 제한적이지 않았습니다. (Bug #32400788)
- 특정 비교 조건자가 평가되는 방식의 불일치(예를 들어 `WHERE` 절의 일부인 경우)로 인해 문자열 리터럴 대신 함수를 사용하면 서로 다른 결과가 반환될 수 있었습니다. (Bug #32345941, Bug #102151)

- [`ENUM`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/enum.html) 또는 [`SET`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set.html) 타입의 컬럼은 숫자 비교를 기반으로 정렬되지만, 윈도우 함수의 범위 표현식(즉, range frame specification의 경우 정렬에 사용되는 표현식)에 대한 비교 함수는 컬럼의 결과 타입을 기반으로 설정되며, `ENUM` 및 `SET`의 경우 이는 `String`입니다. 그 결과, 윈도우 프레임에 대한 로우 처리(로우가 프레임 앞에 있는지 뒤에 있는지 확인하는 처리)가 올바르게 작동하지 않았습니다. 예를 들어, 문자열 비교에서는 어떤 로우가 프레임 앞에 있다고 판단할 수 있지만, 숫자 비교에서는 해당 로우가 뒤에 배치되었을 수 있습니다.

이 문제를 해결하기 위해, `ENUM` 및 `SET`에 대한 integer 캐시 항목과, `ENUM` 또는 `SET` 타입이 범위 표현식에 포함될 때 사용할 integer 비교 함수를 구현했습니다. (Bug #32328576)
- 최적화되어 제거되고 정리된 서브쿼리에 접근할 때 DML 문이 서버의 계획되지 않은 종료를 유발했습니다. (Bug #32244822)

- 컬럼을 해석할 때 컬럼 이름은 `utf8_general_ci`를 사용하여 case-insensitive 방식으로 비교되며, 이는 테이블에 실제로 사용되는 콜레이션의 비교 규칙과 항상 동일한 규칙을 따르지는 않습니다. 이전에는 테이블에 32개를 초과하는 컬럼이 있는 경우 이름 조회가 해시 테이블을 사용하여 수행되었습니다. 해싱은 콜레이션을 인식하므로 해당 콜레이션의 비교 규칙을 따르며, 이로 인해 이름 조회와 중복 감지가 일관되지 않은 방식으로 수행되었습니다. 이 문제는 해시를 제거하고, 컬럼 수와 관계없이 모든 경우에 동일한 방식으로 컬럼 이름 해석을 수행하여 해결했습니다. (Bug #32169656)
- nullable 컬럼의 경우 인접한 범위가 range optimizer에 의해 동일한 값으로 반올림되면 잘못된 결과가 반환되었습니다. (Bug #31870920)

참조: 다음도 참조하십시오: Bug #98826, Bug #30988735.
- [`SHOW GRANTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-grants.html) 문에 대한 따옴표 처리가 개선되었습니다. (Bug #31716706)
- 테이블 함수를 뒷받침하는 임시 테이블이 생성되기 전에 [`JSON_TABLE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-table-functions.html#function_json-table) 표현식을 optimizer trace에 기록하려는 시도가 이루어질 수 있었으며, 이로 인해 assertion이 발생했습니다. 이제 컬럼 타입을 아직 사용할 수 없는 경우 `<column type not resolved yet>`가 기록됩니다. (Bug #31578783)

- [`mandatory_roles`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_mandatory_roles) 시스템 변수 설정에 대한 유효성 검사가 이제 [`GRANT role`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/grant.html) 문에 대해 수행되는 유효성 검사와 동기화됩니다. (Bug #31218040)
- [`keyring_hashicorp_update_config()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/keyring-functions-plugin-specific.html#function_keyring-hashicorp-update-config) 함수가 동시 실행에 안전하지 않았습니다. (Bug #31205028)
- 쿼리 rewrite 플러그인은 rewrite 규칙을 새로 고치는 중 rewrite 규칙을 보관하는 테이블에 삭제된 것으로 표시되었지만 물리적으로 제거되지 않은 로우가 포함된 경우 실패했습니다.

이를 수정하기 위해 쿼리 rewrite 플러그인이 이러한 로우를 확인할 때 실패하는 대신 삭제된 로우를 건너뛰도록 했습니다. (Bug #22654105)
- MySQL에서 윈도우 함수를 구현하는 과정의 일부로 수행된 리팩터링으로 인해 `ORDER BY` 절에서 집계의 별칭을 참조할 수 있게 되었지만, 허용되어서는 안 됨에도 이러한 집계에 대한 직접 참조도 허용되었습니다. 이제 서버는 이러한 잘못된 참조를 명시적으로 검사합니다. (Bug #13633829, Bug #30106081)

- 특정 경우에 조건을 파생 테이블로 푸시다운할 때 복제된 뷰 참조가 원하는 컨텍스트에서 항상 확인되지는 않았습니다. 또한 null 조건에 대한 검사가 올바르게 수행되지 않았습니다. (Bug #104574, Bug #33209907, Bug #33197276)
- `HAVING COUNT(DISTINCT...)`를 사용하는 일부 쿼리는 하나의 로우가 예상되는 경우에도 어떤 로우도 반환하지 않았습니다. (Bug #104411, Bug #33152269)

References: 이 문제는 다음의 회귀입니다: Bug #31790217.
- 다중 값 인덱스는 다음 경우에 사용되지 않았습니다:

- 뷰에서
- prepared statement에서
- `OR`를 사용하여 다른 조건자와 결합된 [`MEMBER OF()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-search-functions.html#operator_member-of)를 포함하는 `WHERE`에서

또한 MySQL은 `f() AND f()` 형식의 `WHERE` 절에 대해 `impossible condition`을 잘못 보고했으며, 여기서 *`f()`*&#8203;는 `MEMBER OF()`, [`JSON_CONTAINS()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-search-functions.html#function_json-contains), 또는 [`JSON_OVERLAPS()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-search-functions.html#function_json-overlaps) 중 하나였습니다.

기여해 주신 Yubao Liu에게 감사드립니다. (Bug #104325, Bug #104700, Bug #104721, Bug #33123079, Bug #33268466, Bug #33275457)

References: 다음도 참조하십시오: Bug #102359, Bug #32427727. 이 문제는 다음의 회귀입니다: Bug #30838807.

- `NULL`이 [`REGEXP_INSTR()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/regexp.html#function_regexp-instr)를 호출하는 사용자 생성 함수에 전달되었을 때, 함수의 첫 번째 호출은 예상대로 `NULL`을 반환했지만, 이후 함수의 각 호출도 전달된 값과 관계없이 `NULL`을 반환했습니다. (Bug #104239, Bug #33089668)
- `mbr_utils.cc`에 정의된 일부 함수는 일부 상황에서 힙에 할당된 예외를 throw했습니다. 이러한 경우 예외 객체에 할당된 메모리는 해제되지 않았으며, 이는 예외가 throw될 때마다 소량의 메모리가 누수되었음을 의미했습니다.

이러한 경우 대신 스택에 예외를 할당하도록 하여 수정했습니다. (Bug #104214, Bug #33086286)
- [`subquery_to_derived`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/switchable-optimizations.html#optflag_subquery-to-derived) 최적화가 활성화된 경우 `ROLLUP` 쿼리의 결과에서 컬럼 이름이 올바르게 표시되지 않았습니다. (Bug #104139, Bug #33057397, Bug #33104036)
- `EXISTS`를 사용하는 [`IF`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/if.html) 문을 포함하고, 실행 사이에 삭제되고 다시 생성된 하나 이상의 테이블에 대해 작동하는 저장 프로시저가 첫 번째 호출 이후의 후속 호출에서 올바르게 실행되지 않았습니다. (Bug #103607, Bug #32855634)

- `OR`로 결합된 여러 동일한 범위가 있는 범위 쿼리를 실행할 때(예를 들어 `WHERE (a=1 AND b=2 AND c=3) OR (a=1 AND b=2 AND c=3)`가 있는 쿼리), Optimizer가 범위의 일부를 잃어 최적이 아닌 쿼리 계획을 선택했습니다.

기여해 주신 Facebook에 감사드립니다. (Bug #102634, Bug #32523520)
- 그룹화를 수행하고 최솟값을 찾기 위한 가능한 옵션으로 loose index scan을 평가하는 동안, 비용 계산은 그룹화 속성의 동등 조건자 때문에 쿼리가 하나의 그룹만 살펴본다는 사실을 반영하지 않았습니다. 이로 인해 인덱스에서 로우를 읽은 후 그룹화가 수행되므로 추가 로우를 검사하게 되었습니다.

그룹화 속성에 동등 조건자가 있는지 확인하고 이를 비용 계산에 사용하여 쿼리가 하나의 그룹만 생성하는지 여부를 판단하도록 수정했습니다. 이렇게 하면 Optimizer가 이러한 경우에 유리하다고 판단될 때 loose index scan을 선택합니다. (Bug #101838, Bug #32266286)

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

- 정수 나눗셈을 해석할 때 결과의 정밀도는 피제수에서 가져옵니다. 제수가 십진수인 경우 1보다 작을 수 있으며, 이로 인해 결과가 피제수보다 더 많은 자릿수를 사용하게 될 수 있습니다. 이로 인해 정수 나눗셈의 결과가 decimal 또는 float인 일부 경우에 잘못된 값이 생성되었습니다. (Bug #100259, Bug #31641064)
- 지정된 테이블 중 어느 정도가 버퍼 풀에 버퍼링되어 있는지를 나타내기 위해 optimizer trace에 메모리 내 추정값을 추가했습니다.

기여해 주신 Øystein Grøvlen에게 감사드립니다. (Bug #99993, Bug #31544522)
- DML 문에 대한 [`EXPLAIN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html) 출력은 `SHOW WARNINGS` 출력에 테이블 식별자를 포함하며, 이 식별자에는 일반적으로 데이터베이스 이름이 포함됩니다. [`CREATE VIEW`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-view.html)와 같은 일부 문에서는 데이터베이스 이름이 생략되어야 하며, 이는 캐시된 테이블 객체에서 `alias_name_used` 플래그를 true로 설정하여 강제됩니다. 그러나 `CREATE VIEW` 이후 캐시된 테이블이 재사용될 때 이 플래그가 재설정되지 않았고, 이로 인해 뷰와 동일한 캐시된 테이블에 접근하는 `CREATE VIEW` 이후 실행된 문에 대한 `EXPLAIN` 뒤의 경고에서 데이터베이스 이름이 생략되었습니다.

테이블 초기화 중에 `alias_name_used` 플래그가 항상 적절한 값으로 설정되도록 보장하여 이 문제를 수정했습니다.

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