MySQL 8.0, Descending Index 도입… InnoDB Backward Scan 성능 저하 원인 분석

MySQL 8.0부터 Descending Index가 실제 지원되면서, 정순(ASC)과 역순(DESC)을 혼합한 정렬 쿼리에서 인덱스를 효율적으로 활용할 수 있게 되었다. 이전 버전에서는 문법만 지원되고 실제 역순 인덱스 생성은 불가능했다.

InnoDB 스토리지 엔진에서 Backward Index Scan이 Forward Index Scan보다 느린 이유는 크게 두 가지 구조적 특징 때문이다. 첫째, InnoDB의 페이지 잠금(Latch)은 데드락 방지를 위해 B-Tree 왼쪽에서 오른쪽(Forward) 순서로만 획득하도록 설계되어, Backward 시 복잡한 잠금 획득 및 해제 과정을 거친다. 둘째, 페이지 내부의 레코드는 Single Linked List로 연결되어 있어, Backward Scan 시 Page Directory를 통해 슬롯을 찾은 후 평균 2~4번의 루프를 돌려 이전 레코드를 찾아야 한다.

성능 영향도는 쿼리 패턴에 따라 달라진다. 랜덤한 키 값으로 Index Range Scan을 수행할 때는 약 **10%**의 스루풋 차이를 보이며 CPU 사용량 차이는 미미하다. 그러나 인덱스의 특정 부분(Hotspot)을 집중적으로 읽는 경우, 페이지 잠금 경합으로 인해 최대 **44%**의 스루풋 차이가 발생하고 CPU 사용량도 크게 증가한다.

따라서 소량의 레코드를 드물게 조회하는 쿼리라면 기존 Ascending Index를 Backward Scan으로 읽어도 무방하다. 하지만 빈번하게 실행되거나 인덱스 특정 영역에 대한 잠금 경합이 예상되는 경우, Descending Index를 생성하는 것이 성능 개선과 경합 감소에 도움이 된다. 단, 디스크 I/O가 병목인 환경에서는 이러한 구조적 차이가 Latency에 상쇄되어 영향이 적다.