MySQL은 하나처럼 보이지만, 내부에서는 역할이 분리되어 있습니다

MySQL과 InnoDB를 하나처럼 부르기 쉽지만, 두 계층이 맡는 일은 다릅니다. 위쪽은 SQL을 해석하고 실행 전략을 고르고, 아래쪽은 실제 페이지를 읽고 씁니다. 이 경계를 나눠서 보면 쿼리 성능, 인덱스 동작, 잠금이 왜 한꺼번에 엮이는지 훨씬 빨리 보입니다.

이 구분이 중요한 이유는 모든 최적화가 같은 층위에서 일어나지 않기 때문입니다. 어떤 문제는 파서나 옵티마이저, 실행 엔진 쪽에서 결정되고, 어떤 문제는 실제 데이터를 어떤 구조로 저장하고 어떤 경로로 읽는지에서 시작됩니다.

MySQL 엔진은 결정하고, 스토리지 엔진은 읽고 씁니다

대부분의 SQL 해석과 실행 제어는 MySQL 엔진이 맡고, 실제 데이터 읽기와 쓰기는 스토리지 엔진이 맡습니다. 둘 사이를 이어 주는 경계가 바로 handler입니다.

handler를 기준으로 생각하면 구조가 단순해집니다. MySQL 엔진은 SQL을 받아 파싱하고, 어떤 인덱스를 탈지와 어떤 순서로 실행할지를 결정한 뒤, 필요한 읽기와 쓰기 요청을 handler를 통해 아래로 전달합니다. 그 요청을 받아 실제 페이지를 읽고 변경 사항을 기록하는 쪽이 InnoDB입니다.

그래서 실행 계획을 이해할 때는 “MySQL이 결정했다”와 “InnoDB가 그렇게 저장하고 있다”를 구분해서 보는 편이 좋습니다. 전자는 쿼리의 전략이고, 후자는 데이터를 다루는 물리적 기반이기 때문입니다.

쿼리는 위에서 결정되고, 아래에서 실제로 움직입니다

클라이언트가 SQL을 보내면 MySQL 엔진은 문법을 해석하고, 권한과 캐시 여부를 확인하고, 옵티마이저를 통해 실행 계획을 정한 뒤, 실행 엔진이 handler 호출로 작업을 내려보냅니다. 그 아래에서 InnoDB는 필요한 페이지를 읽고 버퍼링하고 변경을 반영합니다.

실행 계획은 위에서 정해지지만, 비용은 아래에서 지불됩니다. MySQL 엔진이 어떤 순서로 읽을지를 정해도, InnoDB가 실제로 어떤 페이지를 더 읽고 어떤 레코드를 다시 찾아가야 하는지는 또 다른 문제입니다. 같은 쿼리라도 체감이 달라지는 이유가 여기에 있습니다.

InnoDB가 성격을 바꾸는 지점은 클러스터링입니다

InnoDB 구조에서 특히 중요한 건 프라이머리 키 기반 클러스터링입니다. InnoDB 테이블은 프라이머리 키 순서대로 레코드를 정렬해 저장하고, 프라이머리 키 자체가 클러스터드 인덱스 역할을 합니다. 이 특성 때문에 프라이머리 키 레인지 스캔은 매우 효율적일 수 있습니다.

반대로 세컨더리 인덱스는 실제 레코드 위치를 직접 저장하지 않습니다. 세컨더리 인덱스 리프에는 프라이머리 키 값이 들어 있고, 이를 다시 따라가서 실제 레코드를 읽어야 합니다. 그래서 InnoDB를 이해할 때는 “프라이머리 키를 어떻게 잡았는가”가 단순 식별자 선택이 아니라 저장 구조와 조회 경로 자체를 결정한다는 점까지 같이 봐야 합니다.

이 구조는 왜 많은 테이블이 단순하고 짧은 프라이머리 키를 선호하는지도 설명해 줍니다. 프라이머리 키는 클러스터링 기준일 뿐 아니라, 세컨더리 인덱스가 결국 다시 들고 가는 주소이기도 하기 때문입니다.

그래서 InnoDB의 설계 선택은 조회와 잠금에 같이 영향을 줍니다

외래 키, 인덱스, 잠금 전파 이야기도 결국 같은 그림 안에 있습니다. InnoDB가 인덱스와 프라이머리 키를 중심으로 저장 구조를 짜고 있기 때문에, 인덱스 설계는 단순히 조회 성능만 바꾸지 않습니다. 어떤 경로를 따라 레코드를 찾을지, 어떤 인덱스 범위를 잠글지, 외래 키 확인 과정에서 어떤 추가 접근이 필요할지도 함께 바꿉니다.

InnoDB를 볼 때 중요한 건 저장 구조가 조회와 잠금을 따로 움직이지 않는다는 점입니다. 프라이머리 키는 저장 순서를 정하고, 세컨더리 인덱스는 다시 PK를 따라가게 만들고, 그 경로가 곧 읽기 비용이자 잠금 범위가 됩니다. 그래서 MySQL을 이해할 때는 SQL 문장보다 먼저, 지금 문제가 위쪽의 실행 전략인지 아래쪽의 저장 구조인지부터 나눠 보는 편이 맞습니다.

정리

MySQL 엔진과 InnoDB는 같은 시스템 안에 있지만 역할이 다릅니다. MySQL 엔진은 SQL을 해석하고 어떤 방식으로 실행할지 결정합니다. InnoDB는 그 결정을 실제 페이지 읽기와 쓰기, 인덱스 탐색, 버전 관리와 잠금으로 구현합니다.

그래서 MySQL을 이해할 때 중요한 질문은 하나입니다. 지금 보고 있는 문제는 위쪽의 실행 전략 문제인가, 아니면 아래쪽 저장 구조 문제인가입니다. 이 경계를 구분할 수 있어야 쿼리, 인덱스, 잠금을 서로 다른 층위에서 더 정확하게 볼 수 있습니다.