이 포스팅은 Real MySQL의 04장을 읽고 개인적으로 학습하고 이해한 내용입니다. 틀린 부분이 있다면 언제든 지적 부탁드립니다.

Buffer Pool이란?

버퍼와 캐시 혹은 디스크에서 데이터를 읽거나 쓰는 역할을 하는 MySQL 대표 스토리지 엔진 InnoDB에서는 자주 사용되는 데이터를 메모리에 적재하여 빠르게 접근함으로써 전체적인 작업 속도를 향상시킬 수 있는데요. 이 메모리를 버퍼풀이라고 합니다.

이렇게 성능 향상에 긍정적인 영향을 주는 버퍼풀은 MySQL서버 물리 메모리 80%를 버퍼풀로 할당할 정도인데요.
버퍼풀에서 대량의 데이터를 효율적으로 관리하기 위해서는 내부적으로 페이지라는 단위로 나누어서 관리하게 됩니다.

페이지 단위

페이지 단위는 데이터 파일를 의미하는 디스크와 버퍼풀을 의미하는 메모리 사이에서 한 번에 전송될 수 있는 데이터 단위를 의미합니다.

LRU 알고리즘 동작 순서

버퍼풀은 대량의 데이터를 효율적으로 관리하기 위해 페이지라는 단위와 함께 링크드 리스트 자료구조를 사용해 관리하게 됩니다. 링크드 리스트는 LRU 알고리즘에 따라 자주 접근되는 페이지와 접근되지 않는 페이지에 대해 관리하게 되는데요.

내부 링크드 리스트에서는 자주 접근되는 페이지인 new sublist와 잘 접근되지 않는 페이지인 old sublist로 구분하게 됩니다. (old sublist는 리스트의 3/8부분을 사용합니다.)

만약 새로운 데이터 페이지를 디스크로부터 읽게 되면 old sublist의 Head 부분인 Midpoint에 페이지가 삽입됩니다.

old sublist에 페이지를 접근하게 되면 new sublist HEAD에 이동하게 되며, 기존 페이지들은 자연스럽게 밀려나게 되는데요. 이렇게 밀려나면서 old sublist의 tail에 있는 데이터는 버퍼풀에서 삭제되게 됩니다.

간혹 테이블 스캔에 의해 대량으로 읽게되는 데이터가 한번에 버퍼풀에 삽입되는 경우가 있는데요. 이런 경우 기존 old sublist에 있는 대량의 데이터들이 버퍼풀에서 삭제될 수 있습니다. 그리고 이렇게 대량으로 삽입된 old sublist에 있는 페이지들이 1번이라도 접근되는 경우 new sublist에 이동되어 실질적으로 자주 접근되는 데이터가 밀리게 되는 경우가 있습니다. 이런 현상을 최적화 하기 위해 버퍼풀 스캔 저항성과 관련된 내용이 있는데 추후 살펴보도록 하겠습니다.

마무리

실제 성능에 중요한 영향을 끼치는 스토리지 엔진의 버퍼풀의 캐시방식을 알아두는 것은 MySQL 성능 튜닝에 중요한 부분이라고 느끼게 되었는데요. 특히 버퍼풀의 사이즈는 로컬 메모리의 80%를 사용한다고 하지만 실제 서비스되는 서버에서는 어떤 기준치로 용량을 정하게 되는 지 알아둘 필요가 있겠습니다.

참고문서 : https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html