pile·
DB / 데이터·직방직방·

MYSQL 인덱스 튜닝

문제인덱스가 걸려 있는데도 MySQL 쿼리 성능이 안 나오는 네 가지 상황을 다룬다. 손익 분기점, 범위 조건의 비효율, 랜덤 액세스 비용, 중복 인덱스 문제다.
접근EXPLAIN ANALYZE와 I/O 프로파일링으로 실행 계획을 분석하고, 국토부 부동산 실거래 200만 건으로 테스트했다. LIKE를 IN-LIST로 변환하고 커버링 인덱스를 추가하며 중복 인덱스를 통폐합한다.
결과테이블 액세스 I/O가 457,927에서 16,785로 약 3.7% 수준까지 줄었다. 중복 인덱스 정리로 쓰기 I/O는 199,677에서 80,328로 40% 수준으로 떨어졌다.
직방
직방 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  1. DB / 데이터·pinterest-engPinterest Engineering·

    Pinterest 차세대 DB 수집 프레임워크의 자동화된 스키마 진화

    Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

    #data-pipeline#apache-flink#cdc+2