쿼리 튜닝

2차 정렬로 인한 문제

gw1 2025. 9. 27. 23:53

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