개념 설명

먼저 "페이지"가 뭔지

6.1 페이지 압축 - "OS한테 부탁하는 방식"

6.2 테이블 압축 - "MySQL이 직접 하는 방식"

버퍼 풀 이중 관리 - "두 버전을 동시에 들고 다니는 이유"

질문

• 압축이라는 게 이론적으로는 디스크도 아끼고 I/O도 줄고 좋아 보이는데, 실무에서 보면 생각보다 잘 안 쓰는 것 같아요. 혹시 '이 테이블은 압축 써야겠다' 싶었던 케이스가 있으셨나요? 아니면 반대로 쓰려다가 망설였던 경험?
• KEY_BLOCK_SIZE 결정할 때 '실패율 5% 미만'이 기준이라고 나오는데, 근데 만약 로그성 테이블처럼 쓰기만 엄청 많고 읽기는 거의 없는 테이블이면 실패율이 좀 높아도 압축 쓰는 게 나을까요?

정리하면..

압축이 필요한 이유
    └─ 페이지(16KB) 수를 줄여야 I/O가 줄고 쿼리가 빨라짐

방법 1. 페이지 압축
    └─ OS 펀치 홀 이용 → 현실에서 쓰기 까다로움

방법 2. 테이블 압축 ← 실무에서 주로 이걸 씀
    ├─ KEY_BLOCK_SIZE로 목표 크기 설정
    ├─ 실패율 측정해서 적절한 SIZE 결정
    └─ 버퍼 풀에서 압축/해제 버전 동시 관리

<aside> 🐰

압축은 공짜가 아니다. 디스크는 아끼는데, CPU를 쓰고 메모리도 더 쓴다. 그래서 무조건 쓰는 게 아니라 트레이드오프를 따져야 한다.

특히 KEY_BLOCK_SIZE를 너무 작게 잡으면, 압축 실패 → 페이지 스플릿 → 재압축 사이클이 반복되면서 쓰기 성능이 급격히 나빠질 수 있다. 그래서 꼭 실패율 측정 먼저 하고 적용하는 게 맞다.

버퍼 풀 이중 관리는 처음엔 낭비처럼 보이지만, 압축 버전을 보험으로 들고 있으면 메모리가 부족할 때 디스크까지 가지 않아도 되니까 결국 I/O를 한 번 더 아끼는 구조다..!

결국 압축이든 인덱스든 MySQL 튜닝의 핵심은 I/O를 얼마나 줄이냐인 것 같다.

</aside>