CREATE TABLE `board` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT,
`writer_id` bigint unsigned NOT NULL,
`writer_name` varchar(100) NOT NULL,
`title` varchar(50) DEFAULT 'title',
`content` varchar(50) DEFAULT 'hello world',
`deleted` enum('Y','N') NOT NULL DEFAULT 'N',
PRIMARY KEY (`id`),
KEY `idx_writer_name` (`writer_name`),
KEY `idx_writer_id` (`writer_id`),
KEY `deleted` (`deleted`)
) ENGINE=InnoDB AUTO_INCREMENT=3014611 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

전체 게시글 수 = 300 만개
deleted = N 인 게시글 수 = 269만개
인덱스 구성
PRIMARY KEY (`id`),
KEY `idx_writer_name` (`writer_name`),
KEY `idx_writer_id` (`writer_id`),
KEY `deleted` (`deleted`)
실행할 쿼리
explain select * from board where deleted = 'N' order by writer_name, writer_id limit 10, 10;
상황 설명 : deleted = 'N' 인 게시글을 1차 정렬 이름순(동명이인 가능)으로, 같은 이름의 경우엔 writer_id로 2차 정렬을 진행
offset limit 페이징 조회 방식입니다.
단, 여기서 offset이 큰 경우는 당연히 느릴 수 밖에 없어 offset 값이 작은 페이징으로 제한합니다.
페이지 당 10개로, 적당히 초반에 30페이지 쯤 까지만 조회가 가능하다고 가정
큰 offset을 의도한 문제가 아닙니다.


해당 쿼리 실행 시 11~12초가 걸려서 고객에게 컴플레인 발생, 해당 기능 서비스가 불가능함
제한 사항 :
1. 인덱스 구성 변경 불가능
2. 반드시 개선 후에도 동일한 결과를 클라이언트 사용자에게 전달해야함
3. 캐싱은 안됨
그외엔 제한 사항 없음 모두 가능
사용자 화면에 1 초 내로 결과가 뜨도록 개선하세요.
'쿼리 튜닝' 카테고리의 다른 글
| 휴먼 회원 조회 문제 (0) | 2025.12.12 |
|---|---|
| distinct한 값을 빠르게 뽑기 문제 (2) | 2025.11.30 |
| JOIN+Range Scan 충돌 문제 (0) | 2025.10.21 |
| OOM(Out of Memeory) 문제 (5) | 2025.10.05 |
| 최근 접속자 목록 조회 문제 (0) | 2025.08.20 |