데이터가 압축되면 InnoDB 버퍼풀로 읽어야 할 데이터 페이지가 줄어들고 백업 및 복구 시간도 단축된다. 페이지 압축 file-per-table 테이블 스페이스에 저장된 테이블에 제공하는 데이터 페이지 단위 압축이다. MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지를 압축한다. 반대로 디스크에서 데이터 페이지를 읽는 시점에 데이터 페이지를 압축 해제한다. InnoDB와 Disk 간 I/O 시점에 데이터 페이지를 압축, 압축 해제를 한다. 즉, 버퍼 풀의 데이터 페이지는 압축 해제된 상태이다. 그래서 MySQL 서버의 내부 코드는 압축 여부와 관계없이 투명(Transparent)하게 동작한다. 그래서 페이지 압축은 Transparent Page Compression이라고도 불린다. 한 테이블은 ..
어댑티브 해시 인덱스 InnoDB 스토리지 엔진에서 사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스이다. B-Tree 인덱스 VS 어댑티스 해시 인덱스 어댑티브 해시 인덱스는 B-Tree의 검색 시간을 줄여주기 위해 도입되었다. 일반적인 인덱스는 B-Tree로 되어있다. B-Tree는 데이터 탐색을 위해 Root부터 Branch를 거쳐 Leaf까지 탐색을 해야한다. 하지만 해시 인덱스는 데이터를 즉시 찾아갈 수 있다. 해시 인덱스는 인덱스 키 값과 해당 인덱스 키 값이 저장된 데이터 페이지 주소의 쌍으로 관리된다. 인덱스 키 값은 B-Tree 인덱스의 고유 번호와 B-Tree 인덱스의 실제 키 값 조합으로 생성된다. 즉, 모든 B-Tree 인덱스는 하나의 어댑티브 해시 인덱스에 저장되며, ..
언두 로그 InnoDB 스토리지 엔진은 트랜잭션과 격리수준을 보장하기 위해 DML(INSERT, UPDATE, DELETE)로 변경되기 이전 버전의 데이터를 별도로 백업한다. 백업된 데이터를 언두로그(Undo Log)라 한다. 언두로그가 어떻게 사용되는지 간단히 살펴보자. 트랜잭션 보장 트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 변경 전 데이터로 복구해야 한다. 이때 언두 로그를 사용한다. 격리 수준 보장 특정 커넥션에서 데이터를 변경하는 도중 다른 커넥션에서 데이터를 조회하면 트랜잭션 격리 수준에 맞게 변경 중인 레코드를 읽지 않고 언두로그의 데이터를 읽어서 반환한다. 즉, 격리 수준에 따라 보여주는 데이터가 다르다. 언두 로그 모니터링 대용량 데이터 처리 MySQL 5.5 이전 버전에서는 언두..
InnoDB 버퍼 풀 디스크의 파일이나 인덱스 정보를 메모리에 캐시해두는 공간이다. 쓰기 지연을 위한 버퍼로도 사용된다. DML을 통한 데이터 변경은 디스크의 여러 곳에 저장된 레코드를 변경한다. 이는 디스크의 랜덤 I/O를 발생시킨다. 따라서 쓰기 지연을 통해 랜덤 I/O를 줄여 성능을 향샹시킬 수 있다. 데이터 페이지 InnoDB가 디스크와 데이터를 주고 받는 최소 단위를 데이터 페이지라 한다. 데이터 페이지에는 최소 하나의 행이 포함될 수 있다. 하나의 행이 너무 크다면 다음 페이지를 포인터로 쪼개서 데이터 페이지는 전송한다. 구조 InnoDB 버퍼 풀은 메모리 공간을 페이지 단위로 쪼개서 관리한다. 쪼개진 조각을 관리하기 위해 LRU 리스트, Flush 리스트, Free 리스트라는 3개의 자료구조..
InnoDB는 테이블 기반의 잠금이 아닌 레코드 기반의 잠금을 제공한다. 그때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. PK에 의한 클러스터링 InnoDB의 모든 테이블은 PK 값의 순서대로 클러스터링되어 저장된다. 모든 세컨더리 인덱스는 레코드 주소 대신 PK의 값을 논리적인 주소로 사용한다. 테이블이 PK 순서대로 저장되어 있기 때문에 PK를 이용한 레인지 스캔이 상당히 빠르다. 결과적으로 실행계획에서 PK는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정된다. MVCC(Multi Version Concurrency Control) 잠금을 사용하지 않는 일관된 읽기 제공을 위해 하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다. InnoDB는 언두 로그를 이용해 이 기능..
