Official-Dev. blog

파티션 파티션 기능은 테이블을 논리적으로는 하나의 테이블이지만 물리적으로는 여러 개의 테이블로 분리해서 관리할 수 있게 해준다. 주로 대용량의 테이블을 물리적으로 여러 개의 소규모 테이블로 분산하는 목적으로 사용한다. 하지만 파티션을 사용하면 무조건 성능이 빨라지는 것은 아니다. 어떤 쿼리를 사용하느냐에 따라 오히려 성능이 더 나빠지는 경우도 자주 발생한다. 파티션의 동작 원리에 대해 더 깊게 알아보자. 인덱스와의 관계 데이터를 탐색할 때 DB는 인덱스를 메모리에 올려서 사용하게 된다. 인덱스가 커지면 SELECT는 물론이고, INSERT, UPDATE, DELETE 작업도 함께 느려진다. 특히 한 테이블의 인덱스 크기가 물리적 메모리 공간보다 크다면 그 영향은 더 심각해진다. 파티션은 데이터와 인덱스를..

인덱스 알고리즘 인덱스 알고리즘은 인덱스 페이지에 데이터를 저장하거나 찾을 때 사용되는 알고리즘을 의미한다. 대표적으로는 B-Tree 알고리즘과 Hash 알고리즘이 있다. B-Tree 알고리즘 B-Tree는 이진트리와 다르게 하나의 노드에 많은 수의 정보를 가지고 있을 수 있다. M개 자식을 가지는 B 트리를 M차 B-Tree라고 한다. 아래 그림은 차수가 3인 B-Tree 이다. 파란색 부분은 각 노드의 key를 나타낸다. B-Tree 알고리즘은 각 노드의 키보다 작은 값은 왼쪽에, 큰 값은 오른 쪽에 저장하는 방식이다. 이는 다른 알고리즘과 비교했을 때 아래의 특징을 가진다. 각 노드는 항상 정렬된 상태를 가진다. 특정 값보다 크던 작던 간단하게 조회할 수 있다. 데이터가 중복되지 않는다. 참조 포인..

LIMIT Limit 절은 쿼리 결과에서 지정된 순서에 위치한 레코드만 가져오고자 할 때 사용한다. 아래의 예제를 보자. SELECT * FROM employees WHERE emp_no BETWEEN 10001 AND 10010 ORDER BY first_name LIMIT 0, 5; 위의 쿼리는 다음과 같은 순서로 실행된다. employees 테이블에서 WHERE 절의 검색 조건에 일치하는 레코드를 전부 읽어 온다. 1번에서 읽어온 레코드를 first_name 칼럼값에 따라 정렬한다. 상위 5건이 정렬이 완료되면 즉시 쿼리를 멈춘다. 정렬된 결과의 상위 5건만 사용자에게 반환한다. Oracle의 ROWNUM과 달리 MySQL의 LIMIT은 항상 쿼리의 마지막에 실행된다. 즉, 데이터 전체를 조회해서 ..

BETWEEN BETWEEN은 특정 범위를 스캔할 때 주로 사용한다. 개인적으로 IN절에서 여러 개의 값을 전부 명시하는 것보다 BETWEEN처럼 범위로 한 번에 당겨오는 것이 성능상 좋을 것이라고 생각했었다. 정말 그런지 살펴보자. BETWEEN vs IN 절 dept_emp 테이블에 (dept_no, emp_no)로 구성된 PK가 있다고 가정하자. 아래의 SQL 문을 보자. SELECT * FROM dept_emp WHERE dept_no BETWEEN 'd003' AND 'd005' AND emp_no=10001; 문제는 BETWEEN은 범위 안에 있는 모든 레코드를 읽는다는 점이다. 해당 조회는 먼저 BETWEEN으로 모든 레코드를 읽은 후에 emp_no로 조건을 비교한다. 즉, 많은 데이터가 메..

트랜잭션 ? 트랜잭션은 데이터베이스에서 하나의 그룹으로 처리되어야 하는 명령문들을 모아 놓은 논리적인 작업 단위이다. 여러 개의 명령어의 집합이 정상적으로 처리되면 정상 종료되며 하나의 명령어라도 잘못되면 전체가 롤백된다. 트랜잭션을 사용하는 이유 데이터의 일관성을 유지하면서 안정적으로 데이터를 복구하기 위함이다. 데이터베이스에선 테이블에서 데이터를 읽어 온 후 다른 테이블에 데이터를 입력하거나 갱신, 삭제하는데 처리 도중 오류가 발생하면 모든 작업을 원상태로 되돌린다. 처리 과정이 모두 성공했을 때만 최종적으로 데이터베이스에 반영한다. 락(Lock) 트랜잭션을 사용하는 이유가 전체 단위를 롤백만 하기 위한 것은 아니다. DB 락이라는 것이 있는데 여러 사용자가 동일한 데이터를 액세스할 때 작업이 순차적..

커버링 인덱스 커버링 인덱스(Covering Index)는 원하는 데이터를 인덱스에서만 추출할 수 있는 인덱스를 의미한다. B-Tree 스캔만으로 원하는 데이터를 가져올 수 있으며, 칼럼을 읽기 위해 실제 데이터 블록에 접근할 필요가 전혀 없다. 인덱스는 행 전체 크기보다 훨씬 작고 인덱스 값에 따라 정렬이 되기 때문에 Sequential Read로 접근할 수 있기 때문에 쿼리 성능을 크게 향상할 수 있다. 그래서 인덱스를 설계한다고 해서 WHERE 절에 국한된 문제가 아니라, 사실 쿼리 전체에 대해 인덱스 설계가 필요하다. 예시 테이블 생성 create table user ( id int(11) not null auto_increment, name varchar(20) not null default '..

옵티마이저(Optimizer) MySQL에서 쿼리의 결과는 동일하지만 내부적으로 그 결과를 만들어내는 방법은 매우 다양하다. 그런 방법 중에서 어떤 방법이 최적이고 최소의 비용이 소모될 지 결정해야 한다. 쿼리를 최적으로 실행하기 위해 각 테이블의 데이터가 어떤 분포로 저장돼 있는지를 참조하고, 데이터를 기반으로 최적의 실행 계획을 수립해주는 것이 옵티마이저(Optimizer)이다. 어떤 DBMS든 쿼리의 실행 계획을 수립하는 옵티마이저는 가장 복잡한 부분으로 알려져있다. 하지만 실행 계획을 이해해야 실행 계획의 불합리한 부분을 찾아내고, 더 최적화된 방법으로 실행 계획을 수립하도록 유도할 수 있다. 쿼리 실행 절차 MySQL 서버에서 쿼리가 실행되는 과정은 크게 세 단계로 나눌 수 있다. SQL문을 잘..

Using Temporary, Using Filesort Explain 문으로 실행 계획을 확인하면, 늘 눈에 거슬리는 것이 Using Temporary, Using Filesort이다. 이것들이 왜 발생하고 어떠한 영향이 있는 지 알아보자. 임시 테이블(Using Temporary) MySQL 엔진이 스토리지 엔진으로부터 받아온 레코드를 정렬하거나 그룹핑 할 때는 내부적인 임시 테이블을 사용한다. MySQL 엔진이 사용하는 임시 테이블은 처음에는 메모리에 생성됐다가 테이블의 크기가 커지면 디스크로 옮겨진다. 원본 테이블의 스토리지 엔진과 관계없이 임시 테이블이 메모리를 사용할 때는 MEMORY 스토리지 엔진을 사용하며, 디스크에 저장될 때는 MyISAM 스토리지 엔진을 이용한다. 다음은 임시 테이블이 ..

SELECT 쿼리문은 FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY 총 6단계를 거친다. 아래는 각 단계의 동작을 정리한 것이다. FROM 절 (+ Join) 쿼리의 첫번째 실행 순서는 FROM절이다. FROM 절에서는 조회할 테이블을 지정합니다. 이후 Join을 실행하여 하나의 가상 테이블로 결합합니다. WHERE 절 WHERE 절에서는 테이블에서 조건에 맞는 데이터를 필터링한다. GROUP BY GROUP BY 절에서는 선택한 칼럼을 기준으로 조회한 레코드 목록을 그룹핑한다. HAVING 절 HAVING 절은 그룹핑 후에 각 그룹에 사용되는 조건 절이다. 쉽게 말해 그룹을 필터링한다고 생각하면 된다. HAVING 절의 조건을 WHERE 절에도 사용할 수 있는 경..

트랜잭션(Transaction) 종료 시점 "트랜잭션은 언제 종료되는가"에 대해 알아보자. 먼저 트랜잭션의 종료 시점을 알아보기에 앞서 시작 시점을 먼저 알아보자! 트랜잭션이 자동으로 시작되는 시점은 아래와 같다. DML(INSERT, UPDATE, DELETE) 문장이 실행되는 경우 DDL(CREATE, ALTER, DROP) 문장이 실행되는 경우 DCL(GRANT, REVOKE) 문장이 실행되는 경우 트랜잭션은 아래와 같은 상황에 자동으로 종료 된다. COMMIT, ROLLBACK 문을 실행한 경우 DDL 또는 DCL 문 실행 기계 장애 또는 시스템 충돌(crash) deadlock 발생 강제 종료 DDL(Create, Alter, Drop, Truncate) 또는 DCL(Grant, Revoke)문..