서버를 운영하면서 로그 파일의 의미는 아주 중요합니다. 문제가 발생했을 때, 그 원인 파악을 조금 더 쉽게 하도록 하여 해결 시간을 단축할 수 있도록 도와줍니다. 아래 내용은 MySQL 운영시 로그 정보를 저장하는 방법입니다. 1. 기본 로그 설정 - 리눅스 [mysqld] # 에러 로그 설정log-error=/로그저장경로/error.log # 쿼리 로그 설정log=/로그저장경로/query.log # 바이너리 로그 설정log-bin=mysql-bin # 슬로우 쿼리(slow query) 로그 설정log-slow-queries=/로그저장경로/mysql-slow.loglong_query_time=5 # UPDATE 쿼리 설정log-update=update_logs 2. 쿼리 로그 리눅스 환경에서는 my.cn..

지금까지 MySQL에서 쿼리를 처리하는 방식이나 실행 계획에 대해 살펴보겠습니다. 쿼리의 실행 계획만으로도 상당히 내용이 많아서 모두 기억하자면 상당히 힘들 것입니다. 그래서 여기서는 쿼리의 실행 계획을 확인할 때 각 칼럼에 표시되는 값 중에서 특별히 주의해서 확인해야 하는 항목만 간략하게 정리했습니다. Select_type 칼럼의 주의 대상 DERIVEDDERIVED는 FROM 절에 사용된 서브 쿼리로부터 발생한 임시 테이블을 의미합니다. 임시 테이블은 메모리에 저장될 수도 있고 디스크에 저장될 수도 있습니다. 일반적으로 메모리에 저장하는 경우에는 크게 성능에 영향을 미치지 않지만, 데이터의 크기가 커서 임시 테이블을 디스크에 저장하면 성능이 떨어집니다. UNCACHEABLE SUBQUERY쿼리의 FR..

MySQL은 다른 DBMS보다 조인을 처리하는 방식이 단순합니다. 현재 릴리즈된 MySQL의 모든 버전에서 조인 방식은 네스티드-루프로 알려진 중첩된 루프와 같은 형태만 지원합니다. 그리고 조인되는 각 테이블 간의 레코드를 어떻게 연결할지에 다라 여러 가지 종류의 조인으로 나뉩니다. 테이블 조인의 종류조인의 종류는 크게 INNER JOIN과 OUTER JOIN으로 구분할 수 있고, OUTER JOIN은 다시 LEFT OUTER JOIN과 RIGHT OUTER JOIN 그리고 FULL OUTER JOIN으로 구분할 수 있습니다. 그리고 조인의 조건을 어떻게 명시하느냐에 따라 NATURAL JOIN과 CROSS JOIN(ULL JOIN, CARTESIAN JOIN)으로도 구분할 수 있습니다. 조인의 처리에서..

MySQL 정렬의 처리 방식쿼리에 ORDER BY가 사용되면 반드시 다음 3가지 처리 방식 중 하나로 정렬이 처리됩니다. 일반적으로 밑쪽에 있는 정렬 방법으로 갈수록 처리가 느려집니다. 정렬 처리 방법 실행 계획의 Extra 코멘트 인덱스 사용한 정렬 별도의 내용 표기 없음 드라이빙 테이블만 정렬 (조인이 없는 경우 포함) "Using filesort"가 표시됨 조인 결과를 임시 테이블로 저장한 후, 임시 테이블에서 정렬 "Using temporary; Using filesort"가 같이 표시됨 먼저 옵티마이저는 정렬 처리를 위해 인덱스를 이용할 수 있을지 검토할 것입니다. 만약 인덱스를 이용할 수 있다면 별도의 "Filesort" 과정 없이 인덱스를 순서대로 읽어서 결과를 반환합니다. 하지만 인덱스를 ..

DBMS의 쿼리 실행에 같은 결과를 만들어 내는 데 한가지 방법만 있는 것은 아닙니다. 아주 많은 방법이 있지만 그중에서 어떤 방법이 최적이고 최소의 비용이 소모될지 결정해야 합니다. DBMS에서는 쿼리를 최적으로 실행하기 위해 각 테이블의 데이터가 어떤 분포로 저장돼 있는지 통계 정보를 참조하며, 그러한 기본 데이터를 비교해 최적의 실행 계획을 수립하는 작업이 필요합니다. DBMS에서는 옵티마이저가 이러한 기능을 담당합니다. MySQL에서는 EXPLAIN이라는 명령으로 쿼리의 실행 계획을 확인할 수 있으며, 여기에는 많은 정보가 출력됩니다. 실행 계획에 표시되는 내용이 무엇을 의미하고 MySQL 서버가 내부적으로 어떤 작업을 하는지 자세히 살펴보겠습니다. 그리고 어떤 실행 계획이 좋고 나쁜지도 간단히 ..

유니크 인덱스유니크란 사실 인덱스라기보다는 제약 조건에 가깝다고 볼 수 있습니다. 말 그대로 테이블이나 인덱스에 같은 값이 2개 이상 저장될 수 없음을 의미하는데, MySQL에서는 인덱스 없이 유니크 제약만 설정할 방법이 없습니다. 유니크 인덱스에서 NULL도 저장될 수 있는데, NULL은 특정의 값이 아니므로 2개 이상 저장될 수 있습니다. MySQL에서 프라이머리 키는 기본적으로 NULL을 허용하지 않는 유니크 속성이 자동으로 부여됩니다. MyISAM이나 MEMORY 테이블에서 프라이머리 키는 사실 NULL이 허용되지 않는 유니크 인덱스와 같지만 InnoDB 테이블의 프라이머리 키는 클러스터 키의 역할도 하므로 유니크 인덱스와는 근본적으로 다릅니다. 유니크 인덱스와 일반 보조 인덱스의 비교유니크 인덱..

클러스터란 여러 개를 하나로 묶는다는 의미로 주로 사용됩니다. 인덱스에서 클러스터링은 값이 비슷한 것들을 묶어서 저장하는 형태로 구현되는데, 이는 주로 비슷한 값들을 동시에 조회하는 경우가 많다는 점에 착안한 것입니다. MySQL에서 클러스터링 인덱스는 InnoDB와 TokuDB 스토리지 엔진에서만 지원하며, 나머지 스토리지 엔진에서는 지원되지 않습니다. 클러스터링 인덱스클러스터링 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용입니다. 즉 프라이머리 키값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 표현합니다. 중요한 것은 프라이머리 키값에 의해 레코드의 저장 위치가 결정된다는 것입니다. 또한 프라이머리 키값이 변경된다면 그 레코드의 물리적인 저장 위치가 바뀌어야 한다는 것을 ..

전문 검색(Full Text Search) 인덱스인덱스 알고리즘은 일반적으로 크지 않은 데이터 또는 이미 키워드화돼 있는 작은 값에 대한 인덱싱 알고리즘이었습니다. 대표적으로 MySQL의 B-Tree 인덱스는 실제 컬럼의 값이 1MB라 하더라도 1MB 전체의 값을 인덱스 키로 사용하는 것이 아니라 1,000바이트(MyISAM) 또는 767바이트(InnoDB)까지만 잘라서 인덱스 키로 사용합니다. 또한 B-Tree 인덱스의 특성에서도 알아봤듯이 전체 일치 또는 좌측 일부 일치와 같은 검색만 가능합니다. 문서의 내용 전체를 인덱스화해서 특정 키워드가 포함된 문서를 검색하는 전문(Full Text) 검색에는 InnoDB나 MyISAM 스토리지 엔진에서 제공하는 일반적인 용도의 B-Tree 인덱스를 사용할 수 ..

R-Tree 인덱스 아마도 MySQL의 공간 인덱스(Spatial Index)라는 말을 한번쯤 들어본 적이 있을 것입니다. 공간 인덱스는 R-Tree 인덱스 알고리즘을 이용해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스입니다. 기본적인 내부 메커니즘은 B-Tree와 흡사합니다. B-Tree는 인덱스를 구성하는 컬럼의 값이 1차원의 스칼라값인 반면, R-Tree 인덱스는 2차원의 공간 개념 값이라는 것입니다. 최근 GPS나 지도 서비스를 내장하는 스마트 폰이 대중화되면서 SNS 서비스가 GIS와 GPS에 기반을 둔 서비스로 확장되고 있기도 합니다. 이러한 위치 기반의 서비스를 구현하는 방법은 여러 가지가 있겠지만 MySQL의 공간 확장(Spatial Extension)을 이용하면 간단하게 이러한 기..

해시(Hash) 인덱스해시 인덱스는 B-Tree만큼 범용적이지 않지만 고유의 특성과 용도를 지닌 인덱스 가운데 하나입니다. 해시 인덱스는 동등 비교 검색에는 최적화돼 있지만 범위를 검색한다거나 정렬된 결과를 가져오는 목적으로는 사용할 수 없습니다. 일반적인 DBMS에서 해시 인덱스는 메모리 기반의 테이블에 주로 구현돼 있으며 디스크 기반의 대용량 테이블용으로는 거의 사용되지 않는다는 특징이 있습니다. 해시 인덱스 알고리즘은 테이블의 인덱스뿐 아니라 InnoDB의 버퍼 풀에서 빠른 레코드 검색을 위한 어댑티브 해시 인덱스(Adaptive Hash Index)로 사용되기도 하고, 오라클과 같은 DBMS에서는 조인에 사용되기도 합니다. 해시 인덱스는 주로 메모리 기반의 테이블에서 주로 사용되지만 기본적인 특성..