들어가며 첫 발표를 마쳤다! 나를 제외하고도 세 분의 발표자가 더 계셨는데, 모두 유익한 발표였다. (NoSQL, CORS, 암호화까지 모두 정말 좋은 주제!) 발표에 대한 피드백 받기까지 일주일이 좀 더 걸렸지만, 받고나니 정말정말정말정말 뿌듯했다. 피드백 내용을 공유하고, 짧은 발표였지만 회고를 적어보려고 한다. 발표준비 준비는 여러 날에 걸쳐 진행했다. 대략 4-5일 정도 소요되었던 듯하다. 프레젠테이션 자료를 작성한 것은 3-4시간 남짓이었지만, 그 전에 책을 읽고 블로그에 정리하며 이해하는 시간까지 모두 발표를 위한 또 내 공부를 위한 과정이었다. 주제는 준비편에서도 적었듯 MySQL의 B-Tree Index! (시간 관계상 블로그에 적은 것만큼 많은 내용을 다루지는 못해서 아쉬움이 남지만 다음..

들어가며 지난 글인 B-Tree Index(3)에서는 인덱스를 통해 Data를 읽는 방법을 살펴봤다. 그 방법에는 네 가지가 있는데, 아래에 정리했다. (1) Index Range Scan (2) Index Full Scan (3) Loose Index Scan (4) Index Skip Scan 이 글에서는 그 두 번째, Index Full Scan에 대해 정리해보겠다. Index Full Scan 언제 사용될까? 대표적으로, 조건절에 사용된 컬럼이 인덱스를 구성하는 첫번째 컬럼이 아닌 경우에 인덱스 풀 스캔이 적용된다. 다만 쿼리가 인덱스에 명시된 컬럼만으로 조건을 처리할 수 있는 경우 주로 이 방식이 사용되고, 인덱스 뿐 아니라 데이터 레코드까지 모두 읽어야 한다면 절대 이 방식으로 처리되지 않는다..

들어가며 지난 글인 B-Tree Index(1) 에서는 네 부분에 대해 알아보았다. (1) B-Tree의 구조 (2) B-Tree Index를 사용해 레코드를 읽는 방법 (3) B-Tree Index의 추가, 삭제, 변경 (4) B-Tree Index를 사용한 검색 이 글에서는 B-Tree Index 사용에 영향을 미치는 요소에 대해 알아보겠다. B-Tree Index 사용에 영향을 미치는 요소 Page InnoDB 엔진에서 데이터를 저장하는 기본 단위이다. Block이라고도 한다. 디스크 모든 I/O 작업의 최소 작업 단위다. 버퍼 풀에서 데이터를 버퍼링하는 기본 단위이기도 하다. Page의 기본값은 16KB이다. Index도 페이지 단위로 관리되며 루트노드, 브랜치노드, 리프노드를 구분하는 기준 또한..

들어가며 지난 글 Index 에서는 인덱스의 특징과 분류에 대해 알아보았다. 이번 글에서는 다음 네 부분에 대해 다루겠다. (1) B-Tree Index의 구조 (2) Index를 통한 레코드 읽기 방법 (3) Index 추가/삭제/변경 (4) Index를 이용한 검색 알아보기 B B-Tree의 B는 무엇의 약자일까? Binary 라고 생각하기 쉽지만, B-Tree는 이진트리가 아니다. 여기서 B는 'Balanced'의 약자이고, B-Tree의 자식노드 개수는 가변적이다. B-Tree Index는 column 값을 변경하지 않고 저장해 정렬된 상태로 유지한다는 데에서, Balanced의 의미를 유추할 수 있다. 구조 (1) Root Node (2) Branch Node (3) Leaf Node : 레코드..

들어가며 인덱스는 어렴풋이 개념과 사용방법 정도만 알고 있었는데, 이번에 발표를 준비하면서 자세히 알아보게 됐다. 이 글에서는 인덱스에 대해 간단히 알아보고 분류한 뒤 가장 일반적으로 사용되는 B-Tree Index에 대해 정리하겠다. 인덱스란? 인덱스는 쿼리의 성능에서 빼놓고 생각할 수 없는 개념이다. 인덱스에 대해 간단히 알아보자. 특징 컬럼의 값을 key, 레코드가 저장된 주소를 value로 하는 쌍으로 저장되며, 항상 정렬된 상태로 유지된다. 정렬된 상태로 유지해야 하기 때문에 INSERT, UPDATE, DELETE에 많은 비용이 들지만, SELECT 작업 속도를 높이기 위해 사용된다. 즉 인덱스는 저장 성능을 얼만큼 희생하여 읽기 속도를 높이는 방법이므로, 사용에 있어 주의해야 한다. 인덱스를..