이것이 점프 투 공작소

DB에서 쿼리를 작성하면 EXPLAIN 또는 DESC 명령어를 통해 실행계획을 확인합니다.하지만 보다보면 가끔 잘 모르겠는 부분이 있어서..Real MySQL을 보며 공부한 부분을 정리하려합니다. 통계정보와 히스토그램실행계획을 보기 전에 옵티마이저가 어떤식으로 실행계획을 만드는지 간단하게 알아보려고합니다.옵티마이저가 보다 효율적인 실행계획을 만들기 위해 필요한 두가지가 통계정보와 히스토그램입니다.두 정보를 기반으로 어떤 인덱스를 선택할지 JOIN순서를 어떻게 정할지 결정하기 때문입니다. 통계정보는 디스크에 저장되며 테이블이 생성되거나 데이터가 변경될 때 통계정보가 추가 및 변경됩니다.히스토그램은 자동으로 수집되지 않으며, 데이터 분포에 대한 통계정보를 제공합니다. 히스토그램은 아래와 같은 명령어로 생성 ..

웹서비스를 개발하다 보면 실제 운영서버에 반영하기 전에 만들어둔 쿼리에 대한 테스트 및 성능확인이 필요합니다.주로 EXPLAIN 명령어를 통해 쿼리의 성능을 평가했는데, 그냥 인덱스를 잘 타는구나~ 이 정도만 확인했던 기억이 있습니다. 그래서 옵티마이저가 인덱스를 어떻게 확인해서 쿼리에 적용하는지 더 나은 인덱스를 태우려면 어떻게 해야하는지 궁금해서MySQL 옵티마이저에 대해 공부 및 정리해보려고 합니다.(Real MySQL을 보고 공부한 내용을 다룹니다.)쿼리의 실행 절차1. SQL 파싱사용자로 부터 쿼리요청이 들어오면 'SQL 파서 모듈'에서 문장을 적절하게 쪼개어 MySQL서버가 이해할 수 있는 수준으로 분리합니다.(파싱 트리 작업)2. 최적화 및 실행계획 수립 (옵티마이저 일하는 단계)파싱 트리 ..

친구의 추천을 받아 '밑바닥부터 구현하는 컴퓨팅 시스템'책을 읽고있습니다.직접 구현해보는 내용들이 좀 있이서,공부 내용 정리 및 학습 목적으로 책에서 진행한 실습들을 포스팅해보려 합니다. 실습은 공식 사이트에서 Web IDE를 통해 진행하였습니다. 공식사이트 주소https://www.nand2tetris.org/software Software | nand2tetrisTwo OS implementations are supplied: (i) a collection of eight .vm class files, written originally in Jack (just like Unix is written in C), and (ii) a faster implementation of all the OS serv..

요즘 APM을 만드려고 하다보니 오픈소스의 아키텍쳐에 대한 관심이 높아져서Real MySQL을 보고 공부한 InnoDB의 아키텍쳐를 정리해보고자 합니다.책에서 언급하는 8.0이하에서 발생한 이슈들이나 정보들은 정리하지 않았습니다. InnoDB 아키텍쳐레코드 기반 Lock을 제공하기에 높은 동시성 처리가 가능하며 안정적인 엔진입니다.MySQL에서 기본적으로 사용하는 스토리지 엔진입니다. InnoDB의 특징primary key에 의한 클러스터링InnoDB에 저장되는 테이블 레코드들은 기본적으로 pk에 의해 클러스터링 되어 pk값 순서대로 저장됩니다.그렇기에 pk를 이용한 레인지 스캔은 빠른 속도로 처리 될 수 있습니다.또한 세컨더리 인덱스는 레코드의 실제 주소가 아닌 pk의 값을 논리적인 주소로 사용해서 ..

소프트웨어를 만들때 아키텍쳐가 정말 중요한 부분이라는 생각이 점점 커지는 요즘입니다!그래서 Real MySQL 을 읽고 공부한 MySQL과 InnoDB의 엔진 아키텍쳐를 정리해보고자 합니다. MySQL 아키텍쳐 MySQL은 MySQL 엔진 + 스토리지 엔진 두가지 엔진으로 이루어져 있습니다.이 둘을 합하여 MySQL, MySQL서버라고 부릅니다. MySQL 엔진클라이언트로 부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리 최적화 실행을 위한 옵티마이저가 존재합니다.데이터를 디스크에 저장하는 작업 외 전반적인 MySQL기능들은 대부분 MySQL엔진에서 이루어집니다. 스토리지 엔진요청된 SQL을 분석하거나 최적화 하는 중 DBMS의 핵심입니다.실제 데이터를 디스크 스토리지에..