MySQL latch 유형 - btr_search_latch

이 페이지에서는 MySQL 운영중 발생 할 수 있는 latch 인 btr_search_latch 에 대해서 다룬다.

 

해당 내용은 아래의 URL 을 참조한다.

 

[1] https://tech.kakao.com/2016/04/07/innodb-adaptive-hash-index/

 

[2] https://stackoverflow.com/questions/63541711/aws-rds-mysql-innodb-btr-search-latch

 

[3] https://severalnines.com/blog/monitoring-galera-cluster-understanding-and-optimizing-cpu-related-innodb-metrics/

 

또한 해당 내용은 이전 게시글과 연관되어 있다.

 

[4] 2021.03.09 - [DB 관련 지식/DB 기본 개념] - 인덱스 (Index)

 

[5] 2023.06.16 - [DB 관련 지식/DB 기본 개념] - latch, mutex, enqueue

 

 

Adaptive Hash Index (AHI) 개념

 

먼저, btr_search_latch 를 설명하기 위해서는 Adptive Hash Index (AHI) 를 먼저 설명해야 한다. 이 latch 는 AHI 와 매우 밀접하게 연관되어 있기 때문이다.

 

AHI 는 MySQL, MariaDB 에서 사용되는 인덱스 중의 하나로써, B tree index 의 제한 사항을 보완하기 위해 도입된 인덱스다. B-Tree 인덱스는 [1] 의 자료내용과 같이 소량의 데이터에 접근함에도 계층구조를 따르는 B tree index 를 따르는 이상

불필요한 b tree 의 경로를 root 부터 leaf 까지 계속 따라가면서 불필요한 접근 비용을 요구하게 된다.

 

AHI 는 이러한 제한사항을 보완하기 위하여 도입된 개념으로 자주 참조가 되는 데이터 컬럼을 아에 Hash 값으로 저장하여 보관함으로써, 데이터 조회시 B tree 계층을 따르지 않고 Hash 값을 바로 참조하여 조회 하려는 데이터를 참조 할 수 있도록 해준다. 즉, 불필요한 데이터 접근 비용을 줄여서 조회 성능을 향상시킬 수 있는 이점이 있다.

 

 

btr_search_latch 개념

 

그러나, AHI 는 무조건 이점을 주는 것은 아니다. AHI 에 접근하는 세션들은 [3] 의 내용과 같이 조회 데이터의 일관성을 보장하기 위해서 데이터 격리 수준이 (isolation level) serialized 인 형태와 유사하게 자신이 접근 시, 다른 세션들의 접근을 막는다. 그에 따른 latch 가 이 때 발생하며 실제로 특정 세션이 사용하는 리소스에 대한 다른 세션의 접근을 일시적으로 막는다.

 

소, 중규모 동시 트랜잭션에서는 이 이슈가 크게 눈에 띄지 않을 수 있다. 그러나 단시간 내에 수많은 세션들이 AHI 로 구성된 컬럼에 접근하게 된다면 이에 대한 접근성이 역으로 떨어지고 이에 따라 조회 성능이 떨어 질 수 있다.

 

 

btr_search_latch 확인 방법

 

[3] 의 내용과 같이 Show engine innodb mutex 를 사용하면 이를 확인 할 수 있다.

혹은 AWS RDS, Aurora Cluster 내 Performance Insight (PI) 를 사용한다면 해당 latch 를 SQL 대기 유형에서도 확인할 수 있다.

 

 

btr_search_latch 대응

 

위의 내용과 같이 해당 latch 는 AHI 와 매우 밀접한 연관이 있기 때문에, AHI 를 끈 뒤 (파라미터 inno_db_adaptive_hash_index 를 0 으로 설정) 대량의 세션 트랜잭션을 발생시키면서 이슈 쿼리 이외에 다른 쿼리에서 성능저하가 발생하는지 확인하는 게 좋다. 이는 이슈가 되는 쿼리이외에도 다른 쿼리들은 AHI 의 이점을 받고 있었을 수 있기 때문이다. 성능 저하가 발생하지 않는다면, AHI 를 사용하지 않거나, 쿼리를 개선하는 방식으로 이 이슈를 풀어야 한다.