서버를 운영하면서 로그 파일의 의미는 아주 중요합니다. 문제가 발생했을 때, 그 원인 파악을 조금 더 쉽게 하도록 하여 해결 시간을 단축할 수 있도록 도와줍니다. 아래 내용은 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 스토리지 엔진에서만 지원하며, 나머지 스토리지 엔진에서는 지원되지 않습니다. 클러스터링 인덱스클러스터링 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용입니다. 즉 프라이머리 키값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 표현합니다. 중요한 것은 프라이머리 키값에 의해 레코드의 저장 위치가 결정된다는 것입니다. 또한 프라이머리 키값이 변경된다면 그 레코드의 물리적인 저장 위치가 바뀌어야 한다는 것을 ..

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

인덱스는 데이터베이스 쿼리의 성능을 언급하면서 빼놓을 수 없는 부분입니다. MySQL에서 사용 가능한 인덱스의 종류 및 특성에서 각 특성의 차이는 상당히 중요하며, 물리 수준의 모델링을 할 때도 중요한 요소가 될 것입니다. 다른 RDBMS에서 제공하는 모든 기능을 제공하지는 않지만, MySQL에서는 인덱싱이나 검색 방식에 따라 다른 스토리지 엔진을 선택해야 할 수도 있기 때문에 여전히 인덱스에 대한 기본 지식은 중요하며, 쿼리 튜닝의 기본이 될 것입니다. 또한 인덱스에만 의존적인 용어는 아니지만, 자주 언급되는 "랜덤(Random) I/O"와 "순차(Sequential) I/O"와 같은 디스크 읽기 방식도 알아두는 것이 좋습니다. 디스크 읽기 방식컴퓨터의 CPU나 메모리와 같은 전기적 특성을 띤 장치의 ..

RDBMS(Relational Database Management System)는 표 형식으로 데이터를 저장하고 대부분은 SQL 언어로 데이터 조작을 수행하는 시스템입니다. 다양한 데이터를 저장한다거나 강력한 질의를 할 수 있어서 가장 범용성이 높은 스토리지입니다. RDBMS의 오픈소스 구현은 MySQL이나 PostgreSQL 등이 있으며, 두 다 실제 운용환경에서 널리 사용되고 있습니다. 많은 기업에서 MySQL을 범용 스토리지로 사용하고 있습니다. RDMBS 종류마다 각기 특성이 있는데, 최근에는 기능적, 성능적으로 팽팽하게 경쟁하고 있으니, 지금까지 축적된 노하우 등을 기준으로 선택하면 됩니다. MySQL 주요 스토리지 엔진에는 MyISAM과 InnoDB, Maria가 있습니다. MyISAMMyIS..