--- title: "MySQL 8.0.32 릴리스 노트" description: "MySQL 8.0.32 Community Server 릴리스 노트를 한국어로 번역하고, DBA가 참고해야 할 핵심 내용을 함께 정리하였습니다." tags: [ MySQL, 릴리스노트 ] image: "mysql-release-note.png" author: "Oracle" published: "2023-01-17" updated: "" source_url: "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html" --- ## DBA를 위한 핵심 내용 MySQL 8.0.32는 GIPK 복제 확장, `explain_format`, Thread Pool 관찰성, InnoDB INSTANT DDL 후속 안정화가 주요 변경입니다. DBA가 가장 주의할 항목은 `mysqldump --single-transaction --set-gtid-purged=ON`의 일관성 보정을 위해 `FLUSH TABLES WITH READ LOCK`이 추가되면서 발생한 권한 요구입니다. 이 권한 제한은 8.0.33에서 완화되었으므로, 8.0.32를 직접 운영 대상으로 삼는 경우 백업 계정과 자동화 작업을 반드시 사전 검증해야 합니다. 1. `mysqldump --single-transaction`과 `--set-gtid-purged=ON` 조합에서 GTID와 스냅샷 일관성을 맞추기 위해 FTWRL이 수행되며, 8.0.32에서는 이로 인해 `RELOAD` 권한 요구가 추가됩니다. 권한이 제한된 백업 계정은 실패할 수 있으므로 사전 리허설이 필요합니다. 2. 8.0.28 이후 업그레이드 환경에서 `ALGORITHM=INSTANT` 컬럼 추가와 관련된 크래시·손상 가능성이 수정되었습니다. INSTANT ADD/DROP COLUMN을 사용한 테이블이 많다면 업그레이드 전 `CHECK TABLE`, 백업 검증, 복구 리허설을 병행하십시오. 3. `REQUIRE_TABLE_PRIMARY_KEY_CHECK=GENERATE`가 추가되어 특정 복제 채널에서 기본 키 없는 InnoDB 테이블에 생성된 보이지 않는 기본 키를 만들 수 있습니다. 단, Group Replication과는 호환되지 않으므로 채널별 적용 범위를 명확히 분리해야 합니다. 4. `max_join_size`가 비용 추정치가 아니라 베이스 테이블 접근 로우 수 제한에 더 가깝게 동작하도록 변경되었습니다. 기존에 `max_join_size`로 대형 쿼리를 제한하던 환경에서는 차단되는 SQL이 달라질 수 있습니다. 5. `explain_format` 시스템 변수, Thread Pool Performance Schema 컬럼, `FULL` 및 `$` 식별자 사용 중단 경고, 레거시 압축 옵션 사용 중단 경고가 추가되었습니다. 표준 점검 스크립트와 CI의 경고 처리 정책을 업데이트하십시오. 6. 별도 웹 검색에서는 이 버전 전체에 대한 광범위한 신규 회귀 확산은 확인하지 못했습니다. 다만 백업 권한 이슈는 8.0.33에서 완화되었으므로, 가능하면 8.0.33 이상을 기준으로 운영 검증하는 편이 안전합니다. ## Authentication 관련 사항 - 서버는 AD 도메인에 액세스할 수 없는 경우와 같은 실제 LDAP 서버 오류에 대해서만이 아니라, LDAP 인증 실패에 대해서도 `LDAP_OPERATIONS_ERROR`를 반환할 수 있었습니다. 이제 서버는 인증 오류를 나타내기 위해 MySQL 전용 오류 코드인 `LDAP_AUTHENTICATION_ERROR`를 반환합니다. (Bug #100333, Bug #31680279) ## C API 관련 사항 - `sha256_password_auth_client_nonblocking()` 함수는 공개 키를 사용할 수 있는 경우에도 항상 오류를 반환했습니다. (See the MySQL Server Doxygen documentation, available at [https://dev.mysql.com/doc/index-other.html](https://dev.mysql.com/doc/index-other.html).) 이 패치의 여러 수정 사항에 대해 Facebook에 감사드립니다. (Bug #34556764) ## 컴파일 관련 사항 - **Microsoft Windows:** SASL 기반 LDAP 인증은 클라이언트만 지원되므로 `authentication_ldap_sasl` 서버 플러그인은 더 이상 Windows용으로 빌드되지 않습니다. (Bug #34448155) - Windows에서 테스트와 NDB 스토리지 엔진이 활성화된 경우 VS 2022를 사용하여 MySQL 서버를 컴파일하면 "parser-t"라는 이름의 두 프로젝트에 대한 오류가 발생했습니다. case-insensitive 운영 체제에서 충돌을 방지하도록 테스트 이름이 변경되었습니다. (Bug #34790413) - MacOS에서 Xcode 14가 생성하는 사용 중단 경고를 무시하도록 했습니다. 여기에는 `sprintf(3)` 대신 `snprintf(3)`를 사용하라는 제안과 64비트 정수에서 32비트 정수로 변환할 때 정밀도가 손실될 수 있다는 경고가 포함됩니다. (Bug #34776172) - 플러그인에서 boost 라이브러리 사용을 제거했습니다. (Bug #34694419) - 사용되지 않았으므로 '`Makefile`'이라는 이름의 모든 3rd party 파일을 제거했습니다. (Bug #34648199) - clang 15 지원을 추가했습니다. (Bug #34638573) - 사용되지 않는 코드를 찾아 제거했습니다. fastcov를 사용하여 해당 코드를 찾았습니다. (Bug #34583577) - 'gcc 11.2.0 RelWithDebInfo on Ubuntu 22.04' 및 'gcc 8.3.1 on el6'에서 생성되는 경고를 수정하여 ndbcluster 플러그인 빌드와 관련된 코드를 개선했습니다. (Bug #34384889) - 디버깅 및 gcov 보고서를 더 단순화하는 데 도움이 되도록 이제 Bison 및 Flex 소스 파일에 전체 파일 경로를 사용합니다. (Bug #109022, Bug #34776151) - 빌드 사용자가 **mysqld** 임시 디렉터리에 대한 접근 권한이 없으면 MySQL 빌드가 실패했습니다. 이제 `INFO_BIN` 파일을 생성할 때 `--no-defaults`가 사용됩니다. (Bug #108947, Bug #34756282) ## 사용 중단 및 제거 관련 사항 - 따옴표로 처리되지 않은 식별자의 첫 번째 문자로 달러 기호(`$`)를 사용하는 것은 이제 사용 중단되었으며, 경고([`ER_WARN_DEPRECATED_SYNTAX_NO_REPLACEMENT`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_warn_deprecated_syntax_no_replacement))를 발생시키고, 향후 릴리스에서 제거될 수 있습니다. 이는 데이터베이스, 테이블, 뷰, 컬럼, 저장 프로그램 또는 별칭의 이름에 이러한 식별자를 사용하는 문에 영향을 줍니다. 달러 기호로 시작하는 식별자는 따옴표로 처리된 경우, 즉 서버 SQL 모드에 따라 작은따옴표 또는 큰따옴표(`'` 또는 `"`)나 백틱 문자(```)로 구분된 경우에만 계속 허용됩니다. *예*: ``` mysql> TABLE $t; # Unquoted, produces warning +------+ | a | +------+ | 1 | | 2 | +------+ 2 rows in set, 1 warning (0.00 sec) mysql> SHOW WARNINGS\G *************************** 1. row *************************** Level: Warning Code: 1681 Message: '$ as the first character of an unquoted identifier' is deprecated and will be removed in a future release. 1 row in set (0.00 sec) mysql> TABLE `$t`; # Quoted, no warning +------+ | a | +------+ | 1 | | 2 | +------+ 2 rows in set (0.00 sec) ``` 사용자 변수는 이 변경의 영향을 받지 않습니다. 예를 들어, `SELECT 1 INTO @$x` 문은 경고를 생성하지 않습니다. 자세한 내용은 [Schema Object Names](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/identifiers.html)를 참조하십시오. (Bug #34785775, WL #15422) 참조: 함께 참조하십시오: Bug #34684193. - `CLIENT_NO_SCHEMA` 플래그는 사용 중단되었습니다. `CLIENT_NO_SCHEMA`를 [`mysql_real_connect()`](https://docs.oracle.com/cd/E17952_01/c-api-8.0-en/mysql-real-connect.html)의 `client_flag` 인수로 지정하는 클라이언트 프로그램은 이제 연결에서 데이터베이스 값을 현재(또는 기본) 데이터베이스로 설정하도록 해당 플래그와 `db` 인수를 생략할 수 있습니다. 이제 `libmysqlclient` 라이브러리는 [`mysql_real_connect()`](https://docs.oracle.com/cd/E17952_01/c-api-8.0-en/mysql-real-connect.html)가 `CLIENT_NO_SCHEMA`와 함께 호출될 때 표준 오류에 경고를 출력합니다. 또한 연결에 `CLIENT_NO_SCHEMA`가 있는 경우, 서버는 실행되는 모든 prepared statement가 아닌 쿼리에 대해 사용 중단 경고를 추가합니다. (WL #13128) - 이전에 레거시 압축 제어 파라미터는 사용 중단되었으며, 서버에 대한 연결에서 압축 사용을 더 세밀하게 제어할 수 있도록 새 설정 파라미터로 대체되었습니다. 새 파라미터와 사용 중단된 파라미터는 다음과 같습니다: - [`--compression-algorithms`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-options.html#option_general_compression-algorithms) 클라이언트 옵션은 레거시 [`--compress`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-options.html#option_general_compress) 클라이언트 옵션 및 [`Compression`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Compression) 상태 변수의 사용 중단을 가능하게 합니다. - `MYSQL_OPT_COMPRESSION_ALGORITHMS` C API 옵션은 레거시 `MYSQL_OPT_COMPRESS` C API 옵션의 사용 중단을 가능하게 합니다. - [`CHANGE MASTER TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-master-to.html) 문에 대한 `MASTER_COMPRESSION_ALGORITHMS` 옵션은 레거시 [`slave_compressed_protocol`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_slave_compressed_protocol) 시스템 변수의 사용 중단을 가능하게 합니다. 사용 중단된 파라미터는 향후 MySQL 버전에서 제거됩니다. 이제 다음 클라이언트 프로그램은 클라이언트 사용자가 [`--compress`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-options.html#option_general_compress)(또는 해당되는 경우 `-C`)를 사용하여 프로그램 중 하나를 호출할 때 표준 오류에 사용 중단 경고를 출력합니다: **mysqlpump**, **mysqlcheck**, **mysql**, **mysqladmin**, **mysqlbinlog**, **mysqldump**, **mysqlimport**, **mysqlshow**, **mysqlslap**, **mysql_upgrade**, mysqltest. **mysqlbackup** [`--compress`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-options.html#option_general_compress) 옵션은 다른 기능을 가지며 사용 중단되지 않습니다. (WL #13292) ## Generated Invisible Primary Keys (GIPKs) - **Replication:** 이제 복제본이 복제된 상태에서 기본 키가 없는 모든 [`InnoDB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-storage-engine.html) 테이블에 생성된 보이지 않는 기본 키를 추가하도록 할 수 있습니다. 이는 [`CHANGE REPLICATION SOURCE TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html) 문의 `REQUIRE_TABLE_PRIMARY_KEY_CHECK` 옵션에 사용할 수 있는 값으로 `GENERATE`를 추가하여 구현됩니다. `REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE`는 채널별로 사용할 수 있습니다. 복제본이 `ch1` 및 `ch2`라는 두 복제 채널로 설정되어 있고, 여기에 표시된 문을 실행한다고 가정합니다: ``` STOP REPLICA; SET @@sql_require_primary_key = ON; CHANGE REPLICA SOURCE TO REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE FOR CHANNEL ch1; START REPLICA; ``` 이러한 문의 효과는 복제본이 이제 채널 `ch1`에 의해 생성이 복제되는 테이블에 보이지 않는 기본 키를 추가하지만, `ch2`의 컨텍스트에서 생성되는 키 없는 테이블에는 그렇게 하지 않는다는 것입니다. 복제본은 소스에서 설정된 [`sql_generate_invisible_primary_key`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_sql_generate_invisible_primary_key)의 모든 설정을 무시하며, 이 변수는 복제되지 않습니다. (이 동작은 이전 릴리스와 변경되지 않았습니다.) `REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE`는 MySQL Group Replication과 호환되지 않으며, 여기서는 `ON`, `OFF`, `STREAM`만 이 옵션에 대해 지원되는 값입니다. 자세한 내용은 [CHANGE REPLICATION SOURCE TO Statement](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html) 및 [Generated Invisible Primary Keys](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table-gipks.html)를 참조하십시오. (WL #15419) ## Keyring 관련 사항 - `component_keyring_oci` 설정 파일에 지정되고 Oracle Cloud Infrastructure Console에서 가져오거나 Oracle Cloud Infrastructure API를 쿼리하여 얻은 엔드포인트의 호스트 이름은 이제 Oracle Cloud Infrastructure Vault keyring 컴포넌트에 대한 MySQL 설정을 생성할 때 이전에는 제거해야 했던 `https://` 접두사를 유지할 수 있습니다. (Bug #34636297) ## Pluggable Authentication 관련 사항 - Windows에서 클라이언트 측 Kerberos 인증 플러그인은 이제 MIT Kerberos 라이브러리를 통해 GSSAPI를 지원합니다. Windows에서 `authentication_kerberos_client` 인증 플러그인이 지원하는 새 플러그인 옵션을 사용하여 런타임에 SSPI와 GSSAPI 중에서 선택할 수 있습니다. 클라이언트 사용자는 **mysql** 또는 **mysqldump**를 `--plugin-authentication-kerberos-client-mode` 명령줄 옵션과 함께 호출하여 모드를 GSSAPI로 설정합니다. `authentication_kerberos_client` 플러그인의 기본 모드는 SSPI이며, 이전에는 Windows에서 유일한 인증 방식이었습니다. 자세한 내용은 GSSAPI 모드에서 Windows 클라이언트용 Connection Commands를 참조하십시오. (WL #15336) ## 공간 데이터 지원 - MySQL [`ST_Transform()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/spatial-operator-functions.html#function_st-transform) 함수는 이제 EPSG 1042 (Krovak Modified), EPSG 1043 (Krovak Modified (North Orientated)), EPSG 9816 (Tunisia Mining Grid), EPSG 9826 (Lambert Conic Conformal (West Orientated))를 제외한 모든 Cartesian projection을 지원합니다. (Bug #27272733, Bug #34495023, WL #15164) ## SQL 문법 관련 사항 - **중요한 변경:** 이전에 MySQL은 “full”을 테이블, 컬럼, 뷰, 저장 프로시저 또는 저장 함수의 이름으로 사용하는 것뿐만 아니라, 테이블, 뷰 또는 컬럼의 별칭으로 사용하는 것도 지원했습니다. 이 릴리스부터는 “full”(대소문자와 관계없음)을 이러한 방식으로 따옴표 처리되지 않은 식별자로 사용하는 것이 이제 사용 중단되었으며, 경고를 발생시킵니다. 이는 SQL 표준과 더 긴밀하게 맞추기 위한 것으로, SQL 표준에서는 `FULL`이 키워드로 예약되어 있습니다. 예를 들어, 다음 [`CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-table.html) 및 [`DROP TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/drop-table.html) 문은 이제 여기에 표시된 것처럼 경고를 발생시킵니다: ``` mysql> CREATE TABLE full (c1 INT, c2 INT); Query OK, 0 rows affected, 1 warning (0.03 sec) mysql> SHOW WARNINGS\G *************************** 1. row *************************** Level: Warning Code: 4119 Message: Using FULL as unquoted identifier is deprecated, please use quotes or rename the identifier. 1 row in set (0.00 sec) mysql> DROP TABLE full; Query OK, 0 rows affected, 1 warning (0.01 sec) mysql> SHOW WARNINGS\G *************************** 1. row *************************** Level: Warning Code: 4119 Message: Using FULL as unquoted identifier is deprecated, please use quotes or rename the identifier. 1 row in set (0.00 sec) ``` 경고 없이 문을 실행하려면, 다음과 같이 각 문에서 테이블 이름을 백틱 문자(```)로 둘러싸십시오: ``` mysql> CREATE TABLE `full` (c1 INT, c2 INT); Query OK, 0 rows affected (0.03 sec) mysql> DROP TABLE `full`; Query OK, 0 rows affected (0.02 sec) ``` 값 할당의 오른쪽에서 `FULL`을 사용하는 것은 이 변경의 영향을 받지 *않습니다*. 예를 들어, 여기에 표시된 [`SET`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set.html) 문은 계속 유효합니다: ``` mysql> SHOW VARIABLES LIKE '%metadata%'; +---------------------------------------+---------+ | Variable_name | Value | +---------------------------------------+---------+ | binlog_row_metadata | MINIMAL | | innodb_stats_on_metadata | OFF | | performance_schema_max_metadata_locks | -1 | | resultset_metadata | FULL | +---------------------------------------+---------+ 4 rows in set (0.00 sec) mysql> SET @@global.binlog_row_metadata=FULL; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE '%metadata%'; +---------------------------------------+-------+ | Variable_name | Value | +---------------------------------------+-------+ | binlog_row_metadata | FULL | | innodb_stats_on_metadata | OFF | | performance_schema_max_metadata_locks | -1 | | resultset_metadata | FULL | +---------------------------------------+-------+ 4 rows in set (0.00 sec) ``` 자세한 내용은 [키워드 및 예약어](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/keywords.html)를 참조하십시오. (WL #15241) - 이 릴리스에서 추가된 [`explain_format`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_explain_format) 시스템 변수를 사용하여, 쿼리 실행 계획을 가져오고 `FORMAT` 옵션이 없는 모든 [`EXPLAIN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-execution-plan) 문의 출력 기본 형식을 설정할 수 있게 되었습니다. `FORMAT` 옵션과 마찬가지로, 이 변수는 `TRADITIONAL`, `JSON` 또는 `TREE` 값 중 하나를 사용할 수 있습니다. `DEFAULT`도 `TRADITIONAL`의 동의어로 지원됩니다. (`DEFAULT`는 `EXPLAIN`의 `FORMAT` 옵션에서는 지원되지 *않습니다*.) `explain_format` 값이 `TREE`라고 가정하십시오. 이 경우, 그러한 모든 `EXPLAIN` 문의 출력은 `EXPLAIN` 문의 일부로 `FORMAT=TREE`가 지정된 것처럼 트리 기반 형식을 사용합니다. `explain_format`에 설정된 모든 값은 `FORMAT` 옵션에 의해 재정의됩니다. 이는 *`explain_format`*이 *`TREE`*로 설정되어 있더라도, `EXPLAIN`을 호출할 때 `FORMAT=JSON`을 제공하면 `explain_format` 값이 무시되고 결과가 `JSON` 형식을 사용하여 표시된다는 뜻입니다. `explain_format`은 [`EXPLAIN ANALYZE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-analyze)의 동작에도 영향을 줍니다. 이 문은 `TREE` 형식만 지원하므로, explain_format 값이 `TREE`가 아닌 경우 `TREE` 형식을 명시적으로 지정하지 않은 모든 `EXPLAIN ANALYZE` 문은 This version of MySQL doesn't yet support 'EXPLAIN ANALYZE with *`format`* format' 오류를 발생시킵니다. 새 시스템 변수는 전역 및 세션 범위를 모두 가지며, 영속화할 수 있고, 명령줄에서(`--explain-format`으로) 또는 `my.cnf` 옵션 파일에서 설정할 수 있습니다. [`explain_format`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_explain_format)에 대한 설명을 참조하십시오. 추가 정보와 예시는 [실행 계획 정보 얻기](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-execution-plan) 및 [EXPLAIN ANALYZE로 정보 얻기](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-analyze)도 참조하십시오. (WL #15040) 참조: 함께 참조하십시오: Bug #33629360. ## Thread Pool 관련 사항 - 비활성 상태로 인해 연결이 종료될 때마다 thread pool 플러그인은 연결 시간이 초과되었다는 일반 메시지만 출력했으며, 이로 인해 이러한 타임아웃 분석이 필요한 것보다 더 어려워지는 경우가 많았습니다. 새로운 `INFO_LEVEL` 메시지는 thread pool에서 비활성 상태로 인해 연결이 종료되었음을 명확히 하며, 이 판단에 사용된 타임아웃 값도 명확히 합니다. (Bug #34767607) - 이 릴리스에서 Performance Schema [`tp_thread_state`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-tp-thread-state-table.html) 테이블에 추가된 두 컬럼을 통해 스레드의 유형을 식별하고, 이 테이블의 스레드를 Performance Schema [`threads`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-threads-table.html) 테이블의 스레드에 매핑할 수 있습니다. 이제 스레드 유형은 `tp_thread_state` 테이블의 `TP_THREAD_TYPE` 컬럼에 표시되고, 스레드의 고유 ID는 `THREAD_ID` 컬럼에 표시됩니다. 자세한 내용은 [The tp_thread_state Table](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-tp-thread-state-table.html)을 참조하십시오. (Bug #34020058) ## 추가되거나 변경된 기능 - **중요 변경:** OpenSSL 라이브러리가 번들로 제공되는 플랫폼의 경우, MySQL Server에 링크된 OpenSSL 라이브러리가 버전 1.1.1s로 업데이트되었습니다. OpenSSL 버전 1.1.1s에서 수정된 문제는 [https://www.openssl.org/news/cl111.txt](https://www.openssl.org/news/cl111.txt)에 설명되어 있습니다. (Bug #34828308) - 시스템 curl 라이브러리에 링크하는 대신 curl을 포함하는 바이너리 패키지가 curl 7.86.0을 사용하도록 업그레이드되었습니다. (Bug #34828111) - MySQL 8.0.31에서 추가된 내부 리소스 그룹 개선 사항이 리팩터링되었지만, [`Resource_group_supported`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Resource_group_supported) 상태 변수는 계속 지원합니다. (Bug #34702833, Bug #34699751) 참조: 되돌린 패치: Bug #34264356. ## 수정된 버그 - **중요한 변경:** [`max_join_size`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_max_join_size) 시스템 변수의 구현은 최대 로우 수 또는 디스크 seek 수로 문서화되어 있었지만, 로우 수 또는 디스크 seek 수를 직접 확인하지 않았고, 대신 `max_join_size`를 허용할 최대 예상 비용으로 처리했습니다. 비용과 로우 수는 상관관계가 있지만 서로 같지는 않으며, 이로 인해 일부 큰 쿼리가 진행되도록 허용될 때 예기치 않은 결과가 발생할 수 있었습니다. 이 릴리스에서는 `max_join_size`가 사용되는 방식을 변경하여, 이제 베이스 테이블에서의 최대 로우 접근 수를 실제로 제한합니다. 추정값이 베이스 테이블에서 더 많은 수의 로우를 읽어야 함을 나타내면 오류가 발생합니다. 이를 통해 실제 동작이 문서화된 내용에 더 잘 부합하게 됩니다. (Bug #83885, Bug #25118903) - **InnoDB:** 8.0.28에서 업그레이드한 후 감지할 수 없는 문제, 크래시 및 손상이 발생했습니다. 업그레이드 후 삽입되는 모든 새 로우는 `ALGORITHM=INSTANT`로 추가된 모든 컬럼이 materialized되고 version=0을 갖습니다. 새 구현에서는 `ALGORITHM=INSTANT`로 추가된 컬럼이 로우의 가능한 최대 크기가 로우 크기 제한을 초과하면 실패합니다. 따라서 materialized된 `ALGORITHM=INSTANT` 컬럼이 있는 새 로우는 항상 로우 크기 제한 내에 있게 됩니다. (Bug #34558510) - **InnoDB:** SHOW ENGINE INNODB STATUS에서 더 이상 깨진 UTF 문자가 표시되지 않습니다. (Bug #34486877, Bug #108111) - **InnoDB:** Alter 핸들러가 조정되어 `ALGORITHM=INSTANT`로 1024개를 초과하는 컬럼을 추가해도 더 이상 충돌이 발생하지 않습니다. (Bug #34378513, Bug #107854) - **InnoDB:** `ALGORITHM=INSTANT`로 컬럼을 추가한 후, 온라인 rebuild DDL이 더 이상 충돌하지 않습니다. (Bug #33788578, Bug #106279) - **InnoDB:** 여러 adaptive hash index (AHI) 코드 최적화 및 개선이 구현되어, 잠재적인 race condition을 포함한 다양한 문제가 해결되었습니다. (Bug #33601434) - **Replication:** [`CHANGE REPLICATION SOURCE TO`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/change-replication-source-to.html)를 사용하여 서버에서 `SOURCE_HEARTBEAT_PERIOD`가 매우 작은 값(예: 1마이크로초)으로 설정되고, **mysqlbinlog** 클라이언트 프로그램이 [`--read-from-remote-server`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqlbinlog.html#option_mysqlbinlog_read-from-remote-server) 및 [`--stop-never=1`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqlbinlog.html#option_mysqlbinlog_stop-never)로 시작된 경우, 모든 이벤트가 전송되기 전에 바이너리 로그 덤프 스레드가 클라이언트에 `EOF` 패킷을 전송할 수 있었습니다. (Bug #34860923) - **Replication:** 테스트에서 잘못된 오류를 유발하던 `sql/rpl_group_replication.cc`의 assert가 제거되었습니다. (Bug #34619134) - **Replication:** MySQL이 [`--server-id=0`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options.html#sysvar_server_id)으로 시작된 후, [`SET PERSIST server_id=N`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set-variable.html#set-variable-system-variables)(여기서 N은 0보다 큰 정수)을 사용하여 서버 ID를 변경하고 서버를 재시작하려고 하면 다음 결과가 발생했습니다: - [`SELECT @@server_id`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)가 *`N`*을 반환했습니다. - [`START REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/start-replica.html)와 같은 모든 복제 SQL 문이 [`ER_SLAVE_CONFIGURATION`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_slave_configuration)과 함께 거부되었습니다. 이 문제를 수정하기 위해, 이제 이러한 검사가 시작 옵션에 전달된 값이 아니라 서버 변수의 값을 사용하도록 보장합니다. (Bug #34412816) - **Replication:** [`NDB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysql-cluster.html) 바이너리 로그 인젝터가 생성한 압축된 바이너리 로그 이벤트를 복제할 때, 릴레이 로그 위치가 멀티스레드 적용기에서 업데이트되지 않았으며, 이로 인해 복제가 중단되었습니다. (Bug #33889030) 참조: 다음도 참조하십시오: Bug #33784241. - **Replication:** SQL 스레드가 트랜잭션을 처리하는 동안 [`STOP REPLICA SQL_THREAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/stop-replica.html)를 실행하면, 예상대로 SQL 스레드를 종료하기 전에 이벤트 그룹이 완료될 때까지 60초 동안 기다리는 대신 복제가 즉시 중지되었습니다. 이 문제의 근본 원인은 SQL 스레드가 다시 시작된 후 마지막 이벤트 시작 시간을 저장하는 내부 변수가 재설정되지 않았기 때문이었습니다. SQL 스레드가 시작될 때마다 마지막 이벤트 시작 시간을 보관하는 변수를 재설정하여 이 문제를 수정합니다. (Bug #33646899) - **Replication:** 문구가 다른 의미를 암시할 수 있었지만, 로그 메시지 `Setting super_read_only=ON`([`ER_GRP_RPL_SUPER_READ_ON`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_grp_rpl_super_read_on)) 및 `Setting super_read_only=OFF`([`ER_GRP_RPL_SUPER_READ_OFF`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_grp_rpl_super_read_off))는 작업이 시도된 후에만 기록되었으며, 작업이 시도되기 전이나 작업이 진행 중일 때는 기록되지 않았습니다. 이로 인해 변수 설정이 거부되었고, 설정 시도 자체가 기록되기 전에 이 거부가 기록되는 경우 혼란이 발생하기도 했습니다. 이러한 일이 발생하지 않도록, 이제 이 메시지는 작업을 시도하기 직전에 기록됩니다. (Bug #108843, Bug #34728079) - **Replication:** [`relay_log_space_limit`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_relay_log_space_limit) 시스템 변수는 64비트 값이지만, 유효한 최댓값이 내부적으로 32비트 값의 최댓값으로 지정되어 있었습니다. (Bug #106323, Bug #33799840) - **Replication:** 바이너리 로그를 순환할 때 수행되던 `gtid_executed` 테이블의 불필요한 업데이트를 제거했습니다. (Bug #106116, Bug #33759477) - **Group Replication:** MySQL Performance Schema의 [`replication_group_communication_information`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-replication-group-communication-information-table.html) 테이블의 `WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE` 컬럼은 그룹에서 Paxos Single Leader 설정의 런타임 값을 반영하여, 참여하는 멤버에서 [`group_replication_paxos_single_leader`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-system-variables.html#sysvar_group_replication_paxos_single_leader) 값이 무엇이어야 하는지 사용자가 알 수 있게 합니다. single-leader가 활성화된 상태로 부트스트랩되었지만 프로토콜 버전이 이를 지원하지 않는 버전으로 다운그레이드된 그룹은 예상대로 `WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE`을 `0`으로 보고했지만, `group_replication_paxos_single_leader = 0`을 사용하여 인스턴스를 그룹에 참여시키려고 하면 가능하지 않았습니다. 이 문제를 해결하기 위해 동작을 변경하고 `group_replication_paxos_single_leader` 값을 그룹이 실행 중인 통신 버전과 일치하도록 합니다. 이 변수는 MySQL 8.0.27에서 도입되었으므로 이전 버전에서는 알려져 있거나 사용되지 않으며, 따라서 이제 다음 규칙을 적용합니다: - 노드가 MySQL 8.0.26 이하를 실행 중인 그룹에 조인하려고 하고 우리가 버전 8.0.27 이상인 경우, 그룹에 조인하기 전에 `group_replication_paxos_single_leader`가 `OFF`여야 한다는 오류와 함께 해당 시도를 거부합니다 - [`group_replication_set_communication_protocol()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-functions-for-communication-protocol.html#function_group-replication-set-communication-protocol)를 사용하여 8.0.27보다 낮은 버전을 설정하려고 하고 우리가 버전 8.0.27 이상인 경우, `group_replication_paxos_single_leader`가 `OFF`가 아니면 해당 함수 호출을 거부합니다. 또한 `group_replication_set_communication_protocol()` 실행 후 그룹 리더 변경이 허용되는지 여부를 결정하기 위해 확인하는 값도 변경합니다. 이전에는 이 값이 `group_replication_paxos_single_leader`의 런타임 값이었으며, 이 값은 그룹 재부팅 후에만 적용됩니다. 대신 이제 `group_replication_set_communication_protocol()`을 실행할 때 앞서 설명한 `replication_group_communication_information` 테이블의 `WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE` 컬럼에 표시되는 값을 사용합니다. (Bug #34555045, Bug #34828311) - **Group Replication:** 3노드 클러스터에서 모든 노드가 메모리 부족으로 인해 종료되었습니다. 이후 모든 노드가 성공적으로 다시 시작된 후, 클러스터를 다시 온라인 상태로 전환하려고 하면 프라이머리였던 노드가 중단되었습니다. 자세한 내용은 [Rebooting a Cluster from a Major Outage](https://docs.oracle.com/cd/E17952_01/mysql-shell-8.0-en/reboot-outage.html)를 참조하십시오. (Bug #108339, Bug #34564856) - **Group Replication:** 그룹이 [`group_replication_consistency = AFTER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/group-replication-system-variables.html#sysvar_group_replication_consistency)로 실행되고 세컨더리가 불안정한 네트워크와 같은 외부 조건으로 인해 실패한 경우, 세컨더리는 원격 트랜잭션 prepare를 수신하는 동안 Transaction 'GTID' does not exist on Group Replication consistency manager 오류를 때때로 만날 수 있었습니다. 이 문제의 근본 원인은 프라이머리가 세컨더리가 다시 참여할 때 사용된 `View_change_log_event`를 순서와 다르게 로그에 기록할 수 있었다는 점이었습니다. 세컨더리가 프라이머리를 그룹 도너로 사용한 경우, 이로 인해 세컨더리가 그룹을 부적절하게 따라잡고, 결국 그룹 트랜잭션에 대해 잘못된 GTIDs를 생성할 수 있었습니다. Group Replication 프라이머리는 `View_change_log_event`가 모든 선행 트랜잭션 이후에 로그에 기록되도록 보장하지만, 그룹 전역 순서에서 `View_change_log_event` 이후로 순서가 지정된 트랜잭션이 해당 이벤트보다 먼저 로그에 기록될 수 있는 윈도우가 있었습니다. 이 문제를 해결하기 위해, 이제 뷰보다 앞서 순서가 지정된 트랜잭션은 항상 `View_change_log_event`보다 먼저 로깅되고, 뷰보다 뒤에 순서가 지정된 트랜잭션은 항상 이 이벤트 뒤에 로깅되도록 보장합니다. 이는 이제 바이너리 로그 티켓 관리자가 수행하며, 바이너리 로그 그룹 커밋의 트랜잭션이 커밋되는 순서를 보장합니다. (Bug #104980, Bug #33405699) 참조: 함께 참조하십시오: Bug #34746357. - **Microsoft Windows:** Windows 플랫폼에서 MySQL을 컴파일할 때, CMake [`-DWITH_WIN_JEMALLOC`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/source-configuration-options.html#option_cmake_with_win_jemalloc) 옵션이 항상 올바르게 처리되지는 않았습니다. (Bug #108341, Bug #34698376) - **JSON:** [`JSON_ARRAYAGG()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_json-arrayagg) 또는 [`JSON_OBJECTAGG()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/aggregate-functions.html#function_json-objectagg)의 결과를 컬럼에 저장하는 동안, 결과가 `SUM_FUNC_ITEM` 타입의 항목이었기 때문에 데이터 타입 정보가 손실되었습니다. 이를 수정하기 위해 타입 검사를 제거하며, 이 방식으로 원래 타입 정보를 유지합니다. (Bug #108326, Bug #34548259) - 서버에 대한 일부 원격 연결이 올바르게 처리되지 않았습니다. 이 문제는 [`require_secure_transport`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_require_secure_transport) 관련 문제에 대한 이전 수정의 결과로 발생했습니다. (Bug #34857411) 참조: 이 문제는 다음 버그의 회귀입니다: Bug #34094706. - 일부 쿼리 계획은 `sql_optimizer.cc`의 `Key_use_array`에 대한 비결정적 정렬로 인해 안정적이지 않았으며, 이제 이를 `std::sort()` 대신 `std::stable_sort()`로 정렬합니다. (Bug #34823952) 참조: 이 문제는 다음 버그의 회귀입니다: Bug #25965593. - 시스템 OpenLDAP 라이브러리에 링크하지 않고 OpenLDAP를 포함하는 바이너리 패키지는 버전 2.5.13을 사용하도록 업그레이드되었습니다. (Bug #34815046) - 일부 경우에는 인증 중 서버가 MySQL 클라이언트 프로그램에 보낸 예기치 않은 패킷으로 인해 무한 루프가 발생할 수 있었습니다. (Bug #34805922) - GIS 데이터가 윈도우 함수에서 항상 올바르게 처리되지는 않았습니다. (Bug #34778646) - 스레드가 사용자 기본 리소스 그룹(`USR_default`)에 할당된 후에도 삭제된 리소스 그룹의 CPU에 계속 바인딩되어 있었습니다. `USR_default`는 CPU 우선순위가 0이고 CPU affinity가 없으므로, 이 수정으로 이제 스레드는 `USR_default`를 사용하여 모든 CPU에서 실행될 수 있습니다. (Bug #34748973) - JSON 로깅이 활성화된 상태에서 [`audit_log_rotate()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-reference.html#function_audit-log-rotate) 함수를 호출해도 예상대로 파일이 로테이트되지 않았습니다. 로테이트된 파일 이름은 파일에 기록된 마지막 이벤트의 타임스탬프로 구성됩니다. 파일이 비어 있으면 마지막 타임스탬프는 이미 생성된 파일의 타임스탬프와 동일합니다. 이 문제를 수정하기 위해, 파일이 비어 있으면 이제 이 함수는 현재 시간을 사용하여 파일 이름을 지정합니다. (Bug #34733508) - 여러 lateral 파생 테이블이 있는 일부 쿼리는 예상된 결과를 생성하지 않았습니다. (Bug #34716246) - 번들로 제공되는 zlib 라이브러리가 zlib 1.2.13으로 업그레이드되었습니다. 이제 zlib 1.2.13은 지원되는 최소 zlib 버전입니다. (Bug #34711762, Bug #34711758) - 특정 [`INTERSECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/intersect.html) 쿼리가 올바르게 처리되지 않았습니다. (Bug #34642435) - 명시된 최댓값보다 큰 값을 사용하여 [`MAX_EXECUTION_TIME`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/optimizer-hints.html#optimizer-hints-execution-time) Optimizer 힌트를 사용하면 MySQL 8.0.30으로의 업그레이드가 완료되지 않았습니다. 이로 인해 서버가 경고를 보고했으며, 업그레이드 프로세스는 이를 복구할 수 없는 오류로 해석했습니다. (Bug #34607401) - 특정 경우에 윈도우 함수의 평가가 올바르게 수행되지 않았습니다. (Bug #34572136) 참조: 이 문제는 다음의 회귀입니다: Bug #32644631, Bug #32802301. - 일부 CTE가 올바르게 처리되지 않았습니다. (Bug #34572040, Bug #34634469) 참조: 이 문제는 다음의 회귀입니다: Bug #33856374. - 값을 [`FLOAT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/floating-point-types.html)([`CAST(... AS FLOAT)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_cast), [`CONVERT(..., FLOAT)`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_convert), [`JSON_VALUE(... RETURNING FLOAT))`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/json-search-functions.html#function_json-value)로 변환하는 함수 또는 연산자에서 반환되는 값은 내부적으로 이중 정밀도로 저장되므로 내부 표현에 추가 정밀도를 가질 수 있습니다. 이로 인해 이러한 값의 동등성을 확인할 때 예기치 않은 결과가 발생하는 경우가 있었으며, 예를 들어 [`SELECT DISTINCT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)가 중복 값을 반환하고 비교 연산자가 같은 두 값을 같지 않다고 잘못 보고했습니다. 값을 반환하기 전에 추가 이중 정밀도를 제거하고, 이러한 변환 연산자에서 float에서 문자열로의 모든 변환이 double 형식 대신 float 형식을 사용하도록 하여 이 문제를 수정했습니다. (Bug #34554755) - `query_expression::assert_not_fully_clean()`의 assertion을 제거했습니다. (Bug #34526104) - 단일 데이터베이스에 매우 많은 수의 테이블이 있는 상태에서 MySQL 5.7에서 MySQL 8.0으로 업그레이드하면 서버가 과도한 메모리를 소비했습니다. 테이블을 업그레이드할 수 있는지 확인하는 프로세스 중에 모든 데이터 딕셔너리 `Table` 객체를 미리 가져오고, 각각을 처리하면서 그 이름을 가져온 다음, 해당 목록에 대해 [`CHECK TABLE... FOR UPGRADE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/check-table.html#check-table-version-compatibility)를 수행한 것으로 확인되었습니다. 이 경우 모든 객체를 미리 가져올 필요가 없었으며, 메모리 소비에 크게 기여했습니다. 이 문제를 수정하기 위해, 이제 이러한 경우에는 한 번에 하나의 `Table` 객체를 가져오고, 필요한 검사를 수행하며, 그 이름을 가져오고, 해당 객체를 해제한 뒤 다음 객체로 진행합니다. (Bug #34526001) - natural join 컬럼을 생성할 때, 구체화된 파생 테이블의 일부로 추가된 숨겨진 컬럼이 조인 조건을 구성하는 데 사용되며, 이 조건은 나중에 해당 조인이 파생 테이블로 pushdown될 수 있는지 확인하는 데 사용됩니다. 현재 문제는 이 컬럼이 숨겨져 있기 때문에 파생 테이블에서 가져오지 않았을 때 발생했으며, 이는 조건 pushdown 최적화가 활성화되지 않은 경우에도 발생했습니다. 내부적으로 추가된 모든 숨겨진 컬럼을 거부하고, functional index를 위해 추가된 숨겨진 컬럼에 대해서만 거부하지 않도록 하여 이 문제를 해결합니다. (Bug #34523627) - 사용자 변수에서 타입이 일관되게 파생되지 않았습니다. 이는 예를 들어 다음 문을 반복해서 실행하여 확인할 수 있었습니다: ``` CREATE TABLE t AS SELECT @max_error_count UNION SELECT 'a'; SHOW CREATE TABLE t; ``` 이 특정 사례에서 [`SHOW CREATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-create-table.html) 문의 출력은 첫 번째에는 ``@max_error_count` text`를 표시했고, 이후 반복에서는 ``@max_error_count` mediumblob`를 표시했습니다. (두 번째가 올바릅니다.) (Bug #34523475) - 사용자 계정의 호스트 확인을 개선하기 위해 MySQL 8.0.23에서 수행된 작업 이후, 특히 이러한 문을 연속해서 많이 실행할 때 [`CREATE USER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-user.html)가 완료되는 데 필요한 시간이 크게 증가했습니다. 이 릴리스로 업그레이드하기 전에 이러한 문을 연속해서 많이 실행하는 경우, 그 앞에 단일 `CREATE USER 'fakeuser' ACCOUNT LOCK`을 실행하여 이 문제를 우회할 수 있습니다(이를 위해 기존 사용자 이름과 충돌하지 않는 임의의 사용자 이름을 사용할 수 있습니다). 완료되면 다음 문을 실행하여 정리할 수 있으며, 정리해야 합니다: ``` DROP USER 'fakeuser'; FLUSH PRIVILEGES; ``` 자세한 내용은 [Access Control, Stage 1: Connection Verification](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/connection-access.html)를 참조하십시오. (Bug #34449016) - `data_masking` 서버 측 플러그인은 런타임 오류를 발생시키고 예기치 않게 중단될 수 있었습니다. (Bug #34445632) - 과부하 상태에서 스레드 풀을 사용할 때 스택 오버런이 잘못 보고될 수 있었습니다. 이를 유발한 스레드 풀의 경쟁 조건은 추가 스레드 그룹 ID 검사로 방지되었습니다. (Bug #34414959) - 파생 테이블을 병합할 때 중첩 조인 조건이 파생 테이블에 추가되고 기본 테이블이 이 조인 네스트에 추가됩니다. 또한 조인 조건은 파생 테이블과 연결됩니다. 테이블이 외부 조인의 내부 테이블이거나, 테이블이 내부 테이블이고 조인이 세미조인이 아닌 경우 범위 접근에 대한 평가를 건너뜁니다. 파생 테이블의 경우 기본 베이스 테이블이 후자의 종류로 처리되어 범위 분석을 건너뛰었고, 따라서 범위 접근 메서드를 사용할 수 없었습니다. 이 문제를 해결하기 위해 이제 임베딩 테이블이 파생 테이블인 경우 범위 접근에 대해 평가하며, 파생 테이블과 연결된 조인 조건이 범위 최적화에 사용되도록 보장합니다. (Bug #34347116) - 서브쿼리와 함께 실행된 [`LOAD DATA INFILE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/load-data.html) 문은 서버가 잘못된 경고(`Subquery returns more than 1 row`)를 반환하게 할 수 있었습니다. (Bug #34336033) - 내부 임시 테이블에 대한 리소스 할당 처리가 개선되었습니다. (Bug #34174001) - `INSTANT` 알고리즘을 사용한 삭제 후 추가된 특정 컬럼으로 인해 데이터 오류와 서버 종료가 발생할 수 있었습니다. (Bug #34122122) - `SELECT 1 AS one FROM t WHERE 1=(SELECT 1 UNION SELECT 2)`와 같은 쿼리는 다음과 같이 변환됩니다: ``` SELECT 1 AS one FROM t JOIN ( SELECT 1 AS col1 UNION SELECT 2) derived WHERE 1 = derived.col1; ``` 이 경우 Optimizer는 `1 = derived.col1`을 union 안으로 푸시다운하여 `SELECT 2`의 기여분을 제거했으며, 이로 인해 잘못된 결과가 발생했습니다. 이제 이러한 경우에는 조건을 더 이상 푸시다운하지 않습니다. (Bug #33910786) - `ORDER BY`와 `LIMIT` 중 하나 또는 둘 모두를 포함하는 일부 괄호로 묶인 쿼리 표현식이 항상 올바르게 처리되지는 않았습니다. (Bug #33725530) - 모든 `Item` 객체에서 참조 카운트를 사용하여 여러 참조를 가진 item 트리의 보존을 다시 구현했습니다. 또한 이 변경으로 인해 더 이상 필요하지 않은 이전 코드를 제거했습니다. (Bug #33725415) - `innodb_ddl_log` 테이블의 정의가 변경되었을 때 데이터 딕셔너리 업그레이드 중 [`InnoDB`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-storage-engine.html)에서 assert가 발생했습니다. 이는 테이블 및 컬럼 정의에서 `utf8` 및 `utf8_bin`을 각각 `utf8mb3` 및 `utf8mb3_bin`으로 업데이트하는 것처럼 이러한 변경이 사실상 null 작업인 경우에도 발생했습니다. (Bug #33688509) 참조: 이 문제는 다음의 회귀입니다: Bug #33787300. - **mysqldump**로 백업된 데이터와 GTID는 [`--single-transaction`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqldump.html#option_mysqldump_single-transaction) 및 [`--set-gtid-purged=ON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqldump.html#option_mysqldump_set-gtid-purged) 옵션이 모두 사용되었을 때 일관되지 않았습니다. 이는 **mysqldump**가 트랜잭션을 시작한 시점과 `GTID_EXECUTED`를 가져오는 시점 사이에 서버의 GTID가 이미 증가했을 수 있었기 때문입니다. 이 수정으로 **mysqldump**가 생성한 스냅샷과 값이 일관되도록 보장하기 위해 `GTID_EXECUTED`를 가져오기 전에 [`FLUSH TABLES WITH READ LOCK`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html#flush-tables-with-read-lock)이 수행됩니다. 기여해 주신 Marcelo Altmann에게 감사드립니다. *제한 사항*: 이 수정은 `FLUSH TABLES WITH READ LOCK`을 실행하기 위해 [`--single-transaction`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/mysqldump.html#option_mysqldump_single-transaction)을 사용할 때 [`RELOAD`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_reload) 권한 요구사항을 추가합니다. MySQL 팀은 해결책을 조사하고 있습니다. (Bug #33630199, Bug #105761) - [`SET PERSIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/set-variable.html#set-variable-system-variables)는 컴포넌트가 등록한 변수의 점으로 구분된 이름과 [`MyISAM`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/myisam-storage-engine.html) 다중 키 캐시 변수를 허용했지만, [`RESET PERSIST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/reset-persist.html)는 동일한 이름을 문법 오류로 거부했습니다. 이 불일치를 수정하기 위해, 점 문자(`.`)를 포함하는 변수 이름에 대한 지원을 `RESET PERSIST`에 추가했습니다. (Bug #33417357) - 일부 그룹화된 쿼리가 항상 올바르게 처리되지는 않았습니다. (Bug #33294005, Bug #33349994) - 다중 인증이 첫 번째 요소에 `auth_socket` 인증 플러그인을 사용한 경우, 서버는 두 번째 요소 인증 워크플로 중 잘못된 코드를 실행하고 오류 메시지를 반환했습니다. 두 번째 요소는 어떤 인증 플러그인이든 될 수 있었습니다. (Bug #33192223) - [`INSERT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/insert.html) 문에서 컬럼 식별자로 와일드카드를 사용하는 것은 해당 문법이 지원되지 않는데도 파서에서 허용되었으며, 이로 인해 debug 빌드에서는 assert가 발생하고 release 빌드에서는 해당 문이 조용히 거부되었습니다. 이 구문은 가능한 항목에서 문법상 제거되었으며, 이제 엄격하게 문법 오류로 처리됩니다. (Bug #33142665) 참조: 이 문제는 다음 버그의 회귀입니다: Bug #30528450. - 준비된 문에서 일부 유형의 서브쿼리는 서버 종료를 유발할 수 있었습니다. (Bug #33100586) - 일부 부동 소수점 리터럴은 항상 올바르게 처리되지 않았습니다. (Bug #32824429) - 테이블 별칭이 있는 [`DELETE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/delete.html) 문은 간헐적인 서버 종료를 초래할 수 있었습니다. (Bug #32762229) - INFO_SRC 및 INFO_BIN을 mysql-common 패키지에서 mysqld와 동일한 패키지이며 RPM 패키징과 더 일관된 mysql-community-server-core 패키지로 이동했습니다. (Bug #32752147) - `HAVING` 절 내에서 [`MATCH()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/fulltext-search.html#function_match)를 사용하는 일부 쿼리는 올바르게 처리되지 않았습니다. (Bug #32616816, Bug #32934558, Bug #34782389) - 서브쿼리를 포함하는 [`CREATE VIEW`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-view.html) 문은 때때로 debug 빌드에서 assertion으로 이어졌습니다. (Bug #108783, Bug #34703610) - 사용자 정의 SQL 함수에 매개변수로 전달된 동적 매개변수의 데이터 타입 추론은 단일 매개변수에 대해서만 올바르게 수행되었습니다. 매개변수가 둘 이상인 경우 두 번째 및 그 이후 매개변수에는 이러한 추론이 수행되지 않았으며, 그 결과 해당 타입이 항상 `MYSQL_TYPE_INVALID`로 클라이언트에 잘못 보고되었습니다. (Bug #108545, Bug #34629157) - 내부 함수 `clone_os_copy_file_to_buf()`는 부분 읽기가 발생한 경우 버퍼 위치를 전진시키지 않았습니다. 기여해 주신 Laurynas Biveinis에게 감사드립니다. (Bug #108317, Bug #34543194) - 시스템 뷰에 액세스하는 뷰는 pushdown 조건에 시스템 뷰의 native 함수를 사용하는 표현식이 포함된 경우 정상 사용 중에 access-denied 오류가 발생할 수 있었습니다. (Bug #108202, Bug #34515868) - 윈도우 함수를 사용할 때 현재 로우가 일부 경우 잘못된 레코드를 기준으로 자신을 다시 평가할 수 있었습니다. (Bug #108008, Bug #34431996) - [`LIKE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-comparison-functions.html#operator_like) 절을 가진 쿼리의 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html) 안으로 condition pushdown이 수행될 때 올바른 캐릭터셋이 보존되지 않아 (잘못된) 빈 결과가 발생했습니다. 이 문제는 두 부분으로 해결합니다: - `LIKE` 표현식의 resolution을 리팩터링하여 해결합니다. 이전에는 캐릭터셋 결정과 전파가 코드의 두 개의 별도 블록에서 수행되었으며, 이 두 블록이 항상 서로 일관되지는 않았습니다. - 내부 `parse_expression()` 함수에서 복제되는 모든 literal 문자열에 캐릭터셋 prefix를 추가하여 해결합니다. (Bug #107787, Bug #34359297, Bug #34589153) - 일부 다중으로 중첩된 쿼리가 올바르게 수행되지 않았습니다. (Bug #107660, Bug #34321147, Bug #34377854) - `audit_log` 서버 측 플러그인은 실행된 쿼리의 특정 부분만 로깅하는 대신 항상 전체 다중 쿼리를 로깅했습니다. 쿼리 길이가 설정되는 시점을 변경하여 이 문제를 해결했습니다. (Bug #107390, Bug #34207811) - MySQL 8.0.27로 업그레이드한 후, 특정 쿼리가 저장 프로시저 내에서 실행될 때마다 비교적 많은 양의 메모리를 사용하기 시작했습니다. (Bug #107327, Bug #34190122) - **mysqld** 시작 옵션이 `maximum-` 접두사와 함께 사용되면 해당 시스템 변수의 상한은 설정되었지만, 현재 값이 새 제한에 대해 확인되거나 새 제한에 따라 조정되지 않았으므로 일부 경우 명시된 최댓값보다 클 수 있었습니다. 현재 값이 새 사용자 정의 최댓값보다 큰 경우 이를 조정하여 이 문제를 수정했습니다. (Bug #99029, Bug #31072098) - [`mysql_stmt_close()`](https://docs.oracle.com/cd/E17952_01/c-api-8.0-en/mysql-stmt-close.html) C API 함수는 준비된 명령문이 [`KILL QUERY`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/kill.html)를 사용하여 취소된 후 응답을 중지할 수 있었습니다. (Bug #84470, Bug #25584097)