MySQL 9.7 LTS: Hypergraph 옵티마이저와 Enterprise 기능의 Community 개방

# MySQL 9.7 LTS: Hypergraph 옵티마이저와 Enterprise 기능의 Community 개방

MySQL 9.7.0이 2026년 4월 21일 LTS(Long Term Support) 릴리스로 출시됐다. 이번 릴리스의 핵심은 두 가지다. 첫째, Innovation 트랙에서 실험적 기능으로 제공되던 Hypergraph 옵티마이저가 Community Edition에 정식 포함됐다. 둘째, Enterprise Edition 전용이었던 복제·그룹 복제 메트릭과 관리 기능 다수가 Community로 이동했다. MySQL 8.4 LTS(2023년 10월) 이후 약 2년 6개월 만의 LTS다.

LTS 주기와 이번 릴리스의 위치

MySQL은 2023년부터 두 트랙을 병행 운영하고 있다.

Innovation 트랙: 분기마다 신기능 포함 릴리스. 프로덕션 보증 기간은 짧다.
LTS 트랙: 장기 지원. Premier Support 5년 + Extended Support 3년으로 총 8년.

9.7은 8.4 이후 두 번째 LTS다. Innovation 트랙 9.1 ~ 9.6에서 축적된 기능이 이 릴리스에서 공식 LTS 지위를 얻는다. 운영 환경에서 Innovation 트랙을 적용하기 부담스러웠던 팀은 9.7로 한 번에 올라올 수 있다.

Hypergraph 옵티마이저: 무엇이 달라지는가

기존 MySQL 옵티마이저는 테이블 조인 순서를 왼쪽 깊이 우선(left-deep) 트리로만 탐색했다. 조인이 많아질수록 탐색 공간이 기하급수적으로 커지므로, 실제로는 greedy heuristic으로 조기에 가지치기한다.

Hypergraph 옵티마이저는 다른 접근을 사용한다. 조인 관계를 하이퍼그래프로 표현하고, 이 구조 위에서 동적 프로그래밍으로 조인 순서를 탐색한다.

기존 옵티마이저

Left-deep tree 탐색

Greedy heuristic 가지치기

Bushy plan 불가

Interesting order 미반영

→ 단순 쿼리에 충분

Hypergraph 옵티마이저

Hypergraph 표현 + DP 탐색

Bushy join plan 허용

Interesting order 1등급 최적화

비용 기반 NL vs Hash join 선택

→ 복잡 쿼리·분석 쿼리에 유리

Hypergraph 옵티마이저 vs 기존 옵티마이저

Bushy join plan이란 조인 트리의 내부 노드에 복수의 서브트리가 분기할 수 있는 형태다. 예를 들어 A, B, C, D 네 테이블을 조인할 때 기존 옵티마이저는 ((A⋈B)⋈C)⋈D 형태만 탐색하지만, Hypergraph는 (A⋈B)⋈(C⋈D) 같은 형태도 고려한다. 특히 D를 선행 조인해야 C 필터 선택도가 높아지는 경우처럼 조인 순서가 카디널리티에 민감할 때 차이가 크다.

Interesting order는 ORDER BY, GROUP BY, DISTINCT를 위한 정렬 순서를 조인 계획 수립 단계에서 함께 고려하는 개념이다. 기존 옵티마이저는 실행 계획 수립 후 별도 정렬 단계를 붙이는 방식이었는데, Hypergraph는 어떤 조인 순서가 이미 필요한 정렬을 공짜로 제공하는지를 비용 함수 안에서 계산한다.

활성화 방법

9.7에서 Hypergraph 옵티마이저는 기본값이 아니다. 명시적으로 켜야 한다.

-- 세션 단위 활성화
SET optimizer_switch = 'hypergraph_optimizer=on';

-- 글로벌 활성화 (재시작 불필요, 단 신중히)
SET GLOBAL optimizer_switch = 'hypergraph_optimizer=on';

-- 실행 계획 확인
EXPLAIN FORMAT=TREE
SELECT ...;

EXPLAIN FORMAT=TREE는 Hypergraph 플랜을 볼 수 있는 유일한 형식이다. FORMAT=TRADITIONAL은 하위 호환 표시만 제공한다.

주의사항

Hypergraph 옵티마이저는 아직 모든 쿼리 패턴을 지원하지 않는다. 지원 범위 밖 쿼리를 만나면 옵티마이저가 자동으로 기존 경로로 폴백하며, EXPLAIN에 Note: Falling back to old optimizer가 표시된다. 현재 미지원 범위에는 일부 서브쿼리 변환, 특정 창 함수 조합, 공간 인덱스 조인이 포함된다.

JSON Duality Views DML

MySQL 8.4에서 JSON Duality Views가 도입됐을 때 SELECT만 지원됐다. 9.7에서는 DML(INSERT, UPDATE, DELETE)이 Community Edition에도 전면 개방됐다.

JSON Duality View는 관계형 테이블 위에 JSON 문서 뷰를 씌우는 메커니즘이다. 뷰를 통해 JSON 문서를 수정하면 내부적으로 정규화된 테이블에 반영되고, 반대로 테이블 데이터 변경이 뷰에 즉시 반영된다. 이중성(duality)이라는 이름이 붙은 이유다.

-- JSON Duality View 생성 예시
CREATE OR REPLACE JSON RELATIONAL DUALITY VIEW order_view AS
SELECT JSON_OBJECT(
  'orderId' VALUE o.id,
  'customer' VALUE o.customer_name,
  'items' VALUE (
    SELECT JSON_ARRAYAGG(
      JSON_OBJECT(
        'sku' VALUE i.sku,
        'qty' VALUE i.quantity
      )
    )
    FROM order_items i WHERE i.order_id = o.id
  )
)
FROM orders o WITH INSERT UPDATE DELETE;

-- JSON 문서로 조회
SELECT data FROM order_view WHERE data->>'$.orderId' = '1001';

-- JSON 문서로 삽입 (내부적으로 orders, order_items 양쪽에 반영)
INSERT INTO order_view VALUES (
  JSON_OBJECT(
    'customer', 'Alice',
    'items', JSON_ARRAY(
      JSON_OBJECT('sku', 'A100', 'qty', 2)
    )
  )
);

마이크로서비스 환경에서 일부 서비스가 JSON API로, 다른 서비스가 SQL로 같은 데이터에 접근해야 할 때 스키마 이중화 없이 단일 진실 공급원을 유지할 수 있다. 단, 복잡한 뷰 정의에서 DML 가능 범위에는 제한이 있으며, JSON_TABLE이 포함된 뷰나 집계를 포함하는 뷰는 DML이 제한된다.

Enterprise → Community 이전 기능

MySQL 9.7에서 복제 가시성과 관리 기능이 대거 Community로 이동했다.

기능	이전 상태	9.7 이후
Replication Applier Metrics	Enterprise	Community
Group Replication Flow Control Statistics	Enterprise	Community
Group Replication Resource Manager	Enterprise	Community
Group Replication Primary Election	Enterprise	Community
Telemetry (OpenTelemetry 연동)	Enterprise	Community

Replication Applier Metrics는 performance_schema.replication_applier_status_by_worker 뷰에 지연 원인 분류, 적용 처리량, 트랜잭션별 실행 시간을 추가하는 메트릭이다. 기존에는 초 단위 지연(Seconds_Behind_Source)만 볼 수 있었다.

Group Replication Flow Control Statistics는 그룹 복제 쓰기 스로틀링이 실제로 발동된 횟수, 지속 시간, 영향받은 트랜잭션 수를 performance_schema에 노출한다. 스로틀링이 성능 병목인지 판단하는 데 직접적이다.

Telemetry는 OpenTelemetry Protocol(OTLP)로 MySQL 메트릭과 트레이스를 외부로 내보내는 내장 기능이다. 기존에는 Prometheus exporter나 PMM을 통해 우회해야 했던 메트릭 수집이 서버 내부에서 직접 가능해진다.

VECTOR 타입과 JavaScript MLE

Innovation 트랙에서 도입된 두 기능이 LTS에서 공식 지위를 얻었다.

VECTOR 타입은 부동소수점 배열을 네이티브 컬럼으로 저장하고, HNSW 기반 근사 최근접 이웃(ANN) 인덱스를 지원한다. 벡터 유사도 검색을 MySQL 내부에서 처리할 수 있어 벡터 DB를 별도 운영할 필요를 줄인다.

-- VECTOR 컬럼 생성 및 ANN 인덱스
CREATE TABLE embeddings (
  id   BIGINT PRIMARY KEY AUTO_INCREMENT,
  vec  VECTOR(1536) NOT NULL,
  INDEX ann_idx (vec) USING HNSW
    WITH (m = 32, ef_construction = 200)
);

-- 코사인 유사도 KNN 검색
SELECT id, VEC_DISTANCE_COSINE(vec, :query_vec) AS dist
FROM embeddings
ORDER BY dist
LIMIT 10;

JavaScript Stored Routines (MLE)는 서버 내부에서 JavaScript 함수를 실행하는 기능이다. Node.js 엔진을 내장하며, 기존 SQL 스토어드 프로시저보다 표현력 있는 비즈니스 로직을 데이터베이스 쪽에서 처리할 때 쓸 수 있다.

CREATE FUNCTION greet(name VARCHAR(100))
RETURNS VARCHAR(200)
LANGUAGE JAVASCRIPT AS $$
  return `Hello, ${name}! Computed at ${new Date().toISOString()}`;
$$;

두 기능 모두 LTS가 됐으므로 8년 지원 주기 안에서 쓸 수 있다.

Enterprise에 추가된 Dynamic Data Masking

9.7에서 Enterprise Edition에 Dynamic Data Masking이 추가됐다. 기존 MySQL Enterprise Data Masking이 함수 호출 방식이었다면, Dynamic Data Masking은 컬럼 정의 수준에서 마스킹 정책을 선언한다.

-- 마스킹 정책 선언 예시 (Enterprise 전용)
ALTER TABLE customers
  MODIFY COLUMN email VARCHAR(255)
  MASKED WITH (FUNCTION = 'email');

ALTER TABLE customers
  MODIFY COLUMN phone VARCHAR(20)
  MASKED WITH (FUNCTION = 'partial(0, "XXX-XXXX-", 4)');

사용자 권한에 따라 마스킹된 값 또는 원본 값을 투명하게 반환한다. SELECT 쿼리를 수정하지 않아도 되므로 애플리케이션 코드 변경 없이 열람 권한 정책을 적용할 수 있다. GDPR, 개인정보보호법 준수 감사에서 컬럼 수준 접근 제어의 증빙으로 활용 가능하다.

업그레이드 경로와 고려사항

MySQL 9.7 업그레이드 경로

MySQL 8.0은 2026년 4월 30일 Premier Support가 종료됐다(Extended는 2029년까지). 8.0 사용자에게 9.7 LTS 업그레이드는 실질적인 선택지가 됐다. 단, 8.0에서 9.7로의 직접 업그레이드 전 다음 항목을 확인해야 한다.

sql_mode 비호환: 9.0에서 NO_AUTO_CREATE_USER, DB_TRX 등 일부 레거시 모드가 제거됐다. 8.0에서 묵시적으로 설정된 모드를 먼저 목록화해야 한다.
utf8mb3 → utf8mb4: utf8mb3(구 utf8) 컬럼이 남아 있다면 9.x에서 경고가 발생한다. 마이그레이션 전 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4를 완료할 것.
복제 환경 업그레이드 순서: 소스(Primary)를 먼저 올리고 레플리카를 단계적으로 올려야 한다. 역방향(레플리카 먼저)은 지원되지 않는다.

Hypergraph 옵티마이저 도입 전략

한 번에 글로벌 활성화하는 방식보다는 단계적 검증을 권장한다.

-- 1단계: 중요 쿼리만 세션에서 검증
SET optimizer_switch = 'hypergraph_optimizer=on';
EXPLAIN FORMAT=TREE SELECT ...;
-- "Note: Falling back" 메시지가 없는지 확인

-- 2단계: 읽기 전용 레플리카에서 글로벌 활성화 후 모니터링
-- (소스는 그대로)

-- 3단계: 슬로우 쿼리 로그 비교
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log = ON;
-- 24시간 후 비교

-- 4단계: 옵티마이저가 폴백하는 패턴 목록화
-- performance_schema.events_statements_summary_by_digest 활용
SELECT DIGEST_TEXT, AVG_TIMER_WAIT/1e9 AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC LIMIT 20;

폴백이 발생하는 쿼리는 아직 기존 옵티마이저로 처리되므로 안전하지만, 폴백 비율이 높다면 실제 이득이 제한될 수 있다. 대규모 OLAP 쿼리나 다중 조인 리포팅 쿼리가 많은 워크로드에서 효과가 크고, 단순 OLTP 포인트 쿼리 위주 환경에서는 차이가 작다.

운영 가시성: 복제 메트릭 활용

Community로 이전된 Replication Applier Metrics를 실제로 사용하는 방법이다.

-- 워커별 적용 통계 확인
SELECT
  WORKER_ID,
  APPLYING_TRANSACTION,
  LAST_APPLIED_TRANSACTION,
  LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP,
  LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP,
  LAST_APPLIED_TRANSACTION_RETRIES_COUNT,
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER
FROM performance_schema.replication_applier_status_by_worker;

-- 그룹 복제 Flow Control 통계
SELECT *
FROM performance_schema.replication_group_communication_information;

LAST_APPLIED_TRANSACTION_RETRIES_COUNT가 지속적으로 높은 워커가 있다면 해당 트랜잭션 패턴에서 잠금 경합이 반복되고 있다는 신호다. Enterprise를 쓰지 않아도 이 정보를 Prometheus와 Grafana로 내보낼 수 있게 됐다.

정리

MySQL 9.7 LTS에서 운영자가 주목할 변화는 세 가지다.

첫째, Hypergraph 옵티마이저가 Community Edition에 포함됐다. 기본값이 아니므로 optimizer_switch로 명시적으로 켜야 하고, 단계적 검증이 필요하다. 복잡한 다중 조인 쿼리에서 실질적인 성능 차이를 볼 수 있다.

둘째, Enterprise 전용이었던 복제 메트릭과 그룹 복제 통계가 Community로 이전됐다. 별도 PMM이나 상용 모니터링 없이도 복제 지연 원인 분석이 세밀해진다.

셋째, VECTOR 타입과 JavaScript MLE가 LTS에서 공식 지위를 얻었다. Innovation 트랙에서 실험적으로 사용했다면 이제 8년 지원 주기 안에서 쓸 수 있다.

MySQL 8.0 EOL(2026-04-30 Premier Support 종료)을 계기로 9.7 LTS 업그레이드를 검토 중이라면, sql_mode 호환성과 복제 순서를 먼저 확인한 뒤 Hypergraph 옵티마이저는 레플리카에서 단계적으로 검증하는 접근을 권장한다.