JIN_CODER

디비스터디

JIN_Coder — Mon, 30 Oct 2023 02:23:52 +0900

프라이머리 키에 의함 클러스터링

InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링 되어 저장됨

키 값의 순서대로 디스크에 저장됨

모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용됨

레인지 스캔은 빨리 처리됨

쿼리의 실행 계획에서 프라이머리 키는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정

InnoDB 스토리지 엔진과는 달리 myISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않음

외래키 지원

외래키는 데이터베이스 서버 운영의 불편함 때문에 서비스용 데이터베이스에서는 생서하지 않는 경우도 있음

개발 환경에서는 좋은 가드 역할을 하기도 함

외래키는 부모 자식 테이블의 인덱스 생성이 필요하고, 데이터 유무를 체크 하기 때문에 잠금 및 데드락이 발생 할 수 있어서 주의가 필요함

외래키로 인한 데이터 수정 및 삭제 잠금 해제하는 쿼리

SET foreign_key_checks = OFF;

데이터 일관성을 다시 맞춰주고 외래키를 다시 사용해야 함

MVCC(Multi Version Concurrency Control)

일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능

MVCC는 잠금을 사용하지 않는 일관된 읽기를 제공함

InnoDB는 언두로그를 이용하여 MVCC를 구현

UPDATE문장이 실행되면 커밋 실행여부와 관계없이 InnoDB의 버퍼풀은 새로운 값으로 업데이트 함

작업중인 레코드를 조회 하면 어떻게 보여짐?

SELECT * FROM member WHERE m_id = 12;

MySQL 서버의 시스템 변수에 설정된 격리 수준(Isolation Level)에 따라 다름

격리수준

READ_UNCOMMITTED

InnoDB 버퍼풀이 현재 가지고 있는 변경된 데이터를 읽어서 반환함

커밋이 됐든 아니든 변경된 상태의 데이터를 반환

READ_COMMITTED or 그 이상 수준

커밋되지 않았기 때문에 InnoDB버퍼풀이나 데이터 파일에 있는 내용 대신 변경되기 이전의 내용을 보관하고 있는 언두영역의 테이터를 반환

이 과정을 DBMS MVCC라고 함

트랜잭션이 길어지면 예전데이터가 삭제되지 못하고 언두로그에 오랫동안 남아있게 되면서 불필요한 공간이 늘어나는 상황이 생길 수 있음

COMMIT 명령을 실행하면 InnoDB는 더이상의 변경 작업 없이 지금의 상태를 영구적인 데이터로 만듦

롤백을 실행하면 InnoDB의 언두로그에 있는 백업된 데이터를 버퍼풀로 복구 하고 언두로그를 삭제

잠금없는 일관된 읽기

InnoDB 스토리지 엔진은 MVCC 기술을 이용해 잠금을 걸지 않고 읽기 작업이 가능함

잠금을 걸지 않기 때문에 InnoDB에서 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고 읽기 작업이 가능함

격리 수준이 SERIALIZABLE이 아닌 다른 수준에서는 INSERT와 경결되지 않은 순수한 읽기 작업은 다른 트랜잭션의 변경 작업과 관계없이 항상 잠금을 대기하지 않고 바로 실행됨

특정 사용자가 레코드를 변경하고 아직 커밋하기 전 상태일때 다른 사용자가 SELECT 작업을 방해하지 않음

이를 잠금 없는 일관된 읽기 라고 함

InnoDB에서 변경되기 전의 데이터를 읽기 위해 언두로그를 사용함

트랜잭션이 커밋이나 롤백 적용으로 마무리 되어야 언두로그가 삭제됨(불필요공간 정리)

자동 데드락 감지

InnoDB 스토리지 엔진은 내부적으로 잠금이 교착 상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록을 그래프(Wait-for List)형태로 관리함

데드락 감지 스레드가 주기적으로 잠금 대기 그래프를 검사해 교착 상태에 빠진 트랜잭션들을 찾아서 그 중 하나를 강제 종료함

어떤 트랜잭션을 먼저 종료할지는 언두로그의 양이고, 언두로그 레코드를 적게 가진 트랜잭션이 일반적으로 롤백의 대상이 됨

언두로그 레코드가 적으면 롤백해도 처리할 양이 적어 서버의 부하가 적게감

innodb_table_locks 시스템 변수를 활성화 하면 InnoDB 스토리지 엔진 내부의 레코드 잠금뿐만 아니라 테이블 레벨의 잠금까지 감지 할 수 있게 됨(가능하면 innodb_table_locks을 활성화 하자)

데드락 감지 스레드는 잠금 목록을 검사해야 하기 때문에 잠금 상태가 변경되지 않도록 잠금 목록이 저장된 리스트에 새로운 잠금을 걸고 데드락 스레드를 찾음

자동화된 장애 복구

MySQL 서버가 시작될때 완료되지 못한 트랜잭션이나 디스크 일부에 기록된 데이터 페이지 등 일련의 복구 작업이 자동으로 진행됨

MySQl 서버가 시작될 때 항상 자동복구를 수행함

MySQL 서버가 기동되고 InnoDB 테이블이 인식된다면 mysqldump를 이용해 데이터를 가능한 만큼 백업하고 그 데이터로 MySQL 서버의 DB와 테이블을 다시 생성하는 것이 좋음

위 방법을 써도 복구가 안되면 백업을 이용해서 다시 구축하는 방법뿐임

InnoDB 복구를 이용하는 것보다 풀 백업과 바이너리 로그로 복구하는 편이 데이터 손실이 저 적을 수 있음

InnoDB 버퍼 풀

Innodb 스토리지 엔진에서 가장 핵심적인 부분

디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간

버퍼풀 크기 설정

MySQL 5.7이상 부터 InnoDB버퍼풀의 크기를 동적으로 조정할 수 있게 됨

가능하면 InnoDB 버퍼풀의 크기를 적절히 작은 값으로 설정해서 조금씩 상황을 봐가면서 증가시키는것이 좋음

운영체제의 전체 메모리 공간이 8GB 미만이라면 50%만 버퍼풀로 설정, 나머지 메모리 공간으로 MySQL 서버와 운영체제, 다른 프로그램 공간으로 설정하면 좋음

InnoDB 버퍼풀은 innodb_buffer_pool_size 시스템 변수로 크기를 설정 가능하고 동적으로 버퍼풀 크기를 확장 가능함

버퍼풀 크기 변경은 크리티컬한 변경이므로 한가한 시점에 해야함

버퍼풀의 구조

InnoDB 스토리지 엔진은 크게 LRU 리스트, 플러시 리스트, 프리 리스트 3개의 자료구조를 관리함

LRU 리스트를 관리하는 목적은 디스크로 부터 한번 읽어온 페이지를 최대한 오랫동안 InnoDB버퍼풀 메모리에 유지해서 디스크 읽기를 최소화 하는 것

디비 스터디

JIN_Coder — Mon, 23 Oct 2023 04:09:29 +0900

MySQL 엔진 아키텍처

머리 역할 : MySQL 엔진

손발 역할 : 스토리지 엔진

MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원

모든 언어로 MySQL서버에서 쿼리를 사용 할 수 있게 지원

MySQL 엔진

클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션핸들러, SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룸

스토리지 엔진

MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화 하는 등 DBMS의 두뇌에 해당하는 처리를 수행

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분은 스토리지 엔진 담당

MySQL은 하나지만, 스토리지 엔진은 여러개를 동시에 사용 가능

각 스토리지 엔진은 성능 향상을 위햐 키 캐시나 InnoDB 버퍼풀 같은 기능 내장

핸들러 API

핸들러 요청 : 데이터를 쓰거나 읽어야 할 땐느 각 스토리지 엔진에 쓰기 또는 읽기 요청

이때 사용 되는 API 를 핸들러 API 라고함

InnoDB 스토리지 엔진 또한 이 핸들러 API를 이용해 MySQL 엔진과 데이터를 주고 받음

MySQL 스레딩 구조

MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있음

thread/sql/one_connection 스레드만 실제 사용자의 요청을 처리하는 포그라운드 스레드

동일한 이름의 스레드가 2개 이상씩 보이는 것은 MySQL 서버의 설정에 따라 스레드가 동일 작업을 병렬처리 하는 경우

스레드 풀에서는 커넥션과 포그라운드 스레드는 1:1관계가 아니라 하나의 스레드가 여러개의 커넥션 요청을 전담

포그라운드 스레드(클라이언트 스레드)

포그라운드 스레든느 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재

주로 각 클라이언트 사용자가 요청하는 쿼리문장을 처리함

작업 후 커넥션을 종료하면 스레드는 다시 스레드 캐시로 되돌아감

백그라운드 스레드

백그라운드 스레드로 처리되는 작업들

로그 스레드

쓰기 스레드 : 버퍼의 데이터를 디스크로 내려쓰는 작업

쓰기, 읽기 스레드는 2개 이상 지정 가능

쓰기 스레드는 아주 많은 작업을 백그라운드로 처리하기 때문에 일반적인 내장 디스크를 사용할때는 2~4정도, DAS나 SAN과 같은 스토리지를 사용할 때는 디스크를 최적으로 사용 할 수 있을 만큼 충분히 설정하는것이 좋음

메모리 할당 및 사용 구조

MySQL에서 사용되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분 할 수 있음

글로벌 메모리 영역의 모든 메모리 공간은 MySQL서버가 시작되면서 운영체제로부터 할당 됨

MySQL의 시스템 변수로 설정해 둔 만큰 운영체제로부터 메모리를 할당 받음

글로벌 메모리 영역

일반적으로 클라이언트 스레드의 수과 무관하게 하나의 메모리 공간만 할당됨

대표적인 글로벌 메모리 영역

테이블캐시

InnoDB 버퍼풀

InnoDB 어댑티브 해시 인덱스

InnoDB 리두 로그 버퍼

로컬 메모리 영역(세션 메모리 영역)

MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리

클라이언트가 사용하는 메모리 공간

클라이언트와 MySQL 서버와의 커넥션을 세션이라고 함, 세션 메모리 영역이라고 함

로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 정대 공유되어 사용되지 않음

적절한 메모리 공간설정하는것이 중요

각 쿼리의 용도별로 필요할 때만 공간이 할당되고, 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차도 하지 않을 수 있음

커넥션이 열러있는동안 계속 할당 된 상태로 남아있는 공간(커넥션 버퍼나 결과 버퍼), 쿼리를 실행하는 순간에만 할당했다가 다시 해제한느 공간(소트 버퍼, 조인버퍼)

로컬메모리 대표 영역

정렬버퍼

조인버퍼

바이너리 로그 캐시

네트워크 버퍼

플로그인 스토리지 엔진 모델

각 처리 영역에서 데이터 읽기/쓰기 작업은 대부분 1건의 레코드 단위로 처리됨

핸들러 : 프로그래밍 언어에서는 어떤 기능을 호출하기 위해 사용하는 운전대와 같은 역할을 하는 객체

MySQL 엔진은 사람 역할, 스토리지 엔진은 자동차 역할, MySQL 엔진이 스토리지 엔진을 조정하기 위해 핸들러라는 것을 사용함

MySQL엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다는 점

컴포넌트

MySQL8.0부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원됨

쿼리 실행 구조

쿼리파서

사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어 내는 작업

기본문법 오류는 이곳에서 발견

전처리기

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인

해당객체의 존재 여부와 객체의 접근 권한등을 확인하는 과정

옵티마이저

사용자의 요청으로 들어온 쿼리문장을 저렴한 비용으로 가장 빠르게 처리할지 결정

실행 엔진

옵티마이저는 회사의 경영진, 실행엔진은 중간관리자, 핸들러는 각업무의 실무자

실행 엔진으로 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러요청의 입력으로 연결하는 역할을 수행함

쿼리캐시

쿼리캐시는 SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하기 때문에 매우 빠른 성능 보유

데이터가 변경되는 캐시에 저장된 결과 주에서 변경된 테이블과 관련되 것들은 모두 삭제해야했는데, 이는 심각한 동시 처리 성능 저하를 유발함

MySQL 8.0부터는 쿼리 캐시는 MySQL서버의 기능에서 완전히 제거되고 시스템 변수도 모두 제거됨

스레드 풀

내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요철리 많다하더라도 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중 할 수 있게해서 서버의 자원소모를 줄이는 것이 목적

다만, 스레드 풀이 실제 서비스에서 눈에 띄는 성능 향상을 보여준느 경우는 드뭄..

스케줄링 과정에서 CPU시간을 제대로 확보하지 못하는 경우에는 쿼리 처리가 더 느려지는 사례도 발생할 수 있음

스레드풀은 CPU코어의 개수와 맞추는것이 CPu 프로세서 친화도를 높이는데 좋음

모든 스레드 그룹의 스레드가 각자 작업을 처리하고 있는 상태에서 새로운 쿼리 요청이 들어오더라도 스레드풀은 thread_[ool_stall_limit 시간동안 기다려야만 새로운 요청을 처리 할수 있음

트랜잭션 지원 메타데이터

데이터 딕셔너리, 메타데이터 : 데이터베이스 서버에서 테이블의 구조 정보과 스토어드 프로그램등의 정보

MySQL 8.0부터는테이블의 구조 정보나 스토어드 프로그램의 코드관련 정보를 모두 InnoDB의 데이블에 저장하도록 개선됨

디비 스터디

JIN_Coder — Mon, 18 Sep 2023 03:07:06 +0900

GROUP BY 처리

GROUP BY, ORDER BY 은 스트리밍 처리가 불가능함

GROUP BY에 사용된 조건은 인덱스를 사용할 수 없기 때문에 HAVING 절을 튜닝 하려고 인덱스를 생성하거나 다른 방법을 써도 인덱스를 사용할 수 없음

인덱스 스캔 : 인덱스를 차례로 읽는 방법

루스 인덱스 스캔 : 인덱스를 건너뛰면서 읽는 방법

인덱스를 사용하지 못하는 쿼리에서 GROUP BY는 임시테이블 사용

인덱스 스캔을 이용한 GROUP BY(타이트 인덱스 스캔)
GROUP BY칼럼으로 인덱스가 있다면 인덱스를 차례로 읽으면서 그루핑을 수행하고 그 결과를 조인함
GROUP BY가 인덱스를 통해 처리되는 쿼리는 이미 정렬된 인덱스를 읽는 것이므로 쿼리 실행 시점에 추가적인 정렬 작업이나 내부 임시 테이블은 필요하지 않음

루스 인덱스 스캔을 이용하는 GROUP BY

루스 인덱스 스캔 방법은 단일 테이블에 대해 수행되는 GROUP BY 처리에만 사용 가능함

루스 인덱스 스캔에서는 인덱스의 유니크한 값의 수가 적을수록 성능이 향상됨

루스 인덱스 스캔을 할 수 있는 쿼리들

루스 인덱스 스캔을 할 수 없는 쿼리들

임시 테이블을 사용하는 GROUP BY

GROUP BY의 기준 칼럼이 드라이빙 테이블에 있거나 드리븐 테이블에 있거나 상관없이 인덱스를 전혀 사용하지 못할 때 사용됨

GROUP BY가 필요한 경우 내부적으로 GROUP BY 절의 칼럼들로 구성된 유니크 인덱스를 가진 임시 테이블을 만들어서 중복 제거와 집함 함수 연산을 수행함

DISTINCT 처리

특정 칼럼의 유니크한 값만 조회 하려면 DISTINCT를 사용

집합함수가 없는 경우

MIN(), MAX(), COUNT() 같은 집합 함수와 함께 사용되는 경우

구분한 이유는 각 경우에 DISTINCT 키워드가 영향을 미치는 범위가 달라짐

DISTINCT 처리가 인덱스를 사용하지 못할 땐 임시 테이블을 사용

SELECT DISTINCT ...

SELECT 에서 유니크한 값을 가져오기 위해 DISTINCT를 사용하면 GROUP BY와 같은 방식으로 처리됨

DISTINCT는 SELECT 하는 레코드를 유니크하게 조회 하는것이지 특정 칼럼만 가져오는게 아님

SELECT DISTINCT first_name, last_name FROM employee;

first_name만 유니크한 값을 찾는게 아니라 (first_name, last_name) 조합이 유니크한 값을 찾는거임

SELECT DISTINCT(first_name), last_name FROM employee;

에러는 안나지만, DISTINCT는 함수가 아니라 ()를 사용하지 않고, ()는 제거하고 쿼리문이 실행되서 위 쿼리랑 같은 동작을 함

SELECT 절에 사용한 DISTINCT은 코든 칼럼에 영향을 미친다

?? 칼럼? 레코드가 아니라?

집합 항수와 함께 사용된 DISTINCT

집합 함수 내에서 사용된 DISTINCT는 그 집합 함수의 인자로 전달된 칼럼 값이 유니크한 것들을 가져옴

내부적으로는 COUNT(DISTINCT s.salary)를 처리하기 위해 임시테이블을 사용함

employee, salary 테이블을 조인한 결과에서 salary 칼럼의 값만 저장하기 위한 임시테이블을 만들어 사용함

COUNT(DISTINCT s.salary), COUNT(DISTINCT e.last_name)를 처리하기 위해 임시테이블을 2개를 사용함

인데스된 칼럼에 대해 DISTINCT 처리를 수행 하면 인덱스를 푸스캔하거나 레인지 스캔하면서 임시 테이블 없이 최적화된 처리가 가능함

내부 임시 테이블 활용

일반적으로 MySQL 엔진이 사용하는 임시 테이블은 처은에는 메모리에 생성됐다가 테이블의 크기가 커지면 디스크로 옮김

내부적인 임시테이블은 쿼리의 처리가 완료되면 자동 삭제됨

메모리 임시 테이블과 디스크 임시 테이블

MySQL 8.0부터 메모리는 TempTable이라는 스토리지 엔진을 사용하고, 디스트에 저장되는 임시 테이블은 InnoDB스토리지 엔진을 사용하도록 개선함

임시 테이블이 필요한 쿼리

MySQL 엔진에서 별도의 데이터 가공 작업을 필요로 하므로 대표적인 내부 임시 테이블으 생성하는 케이스

일반적으로 유니크 인덱스가 있는 내부 임시 테이블은 그렇지 않은 쿼리보다 처리 성능이 상당히 느림

임시테이블이 디스크에 생성되는 경우

내부 임시 테이블은 기본적으로 메모리 상에 만들어지지만, 메모리 임시 테이블을 사용할 수 없는 경우에는 디스크 기반의 임시테이블을 사용

디비 스터디

JIN_Coder — Mon, 11 Sep 2023 01:35:27 +0900

쿼리의 실행 절차

DBMS에서 쿼리의 실행 계획을 수립하는 것은 옵티마이저

1단계 : SQL 파싱, MySQL서버의 SQL 파서 라는 모듈로 처리, SQL 문장이 문법적으로 잘못됐다면 여기서 걸러짐

SQL 파스 트리가 만들어짐

2단계 : 최적화 및 실행 계획 수립 단계

불필요한 조건 제거 및 복잡한 연산의 단순화

여러 테이블의 조인이 있는 경우 어떤 순서로 테이블을 읽을지 결정

각 테이블에 사용된 조건과 인덱스 통계정보를 이용해 사용할 인덱스를 결정

가져온 레코드들을 임시테이블에 넣고 다시 한번 가공해야 하는지 결정

3단계 : 수립된 실행 계획대로 스토리지 엔진에 에코드를 읽어오도록 요청하고, MySQL엔진에서는 스토리지 엔진으로 부터 받은 레코드를 조인하거나 정렬하는 작업 수행

옵티마이저 종류

옵티마이저는 DB 서버에서 두뇌 같은 역할을 담당

비용 기반 최적화 방법 : 워리를 처리하기 위한 여러가지 가능한 방법을 만들고, 각 단위 작업의 비용(부하) 정보와 대상 테이블의 예측된 통계정보를 이용해 실행 계획별 비용을 산출함(요즘 많이 사용됨, MySQL)

규칙 기반 최적화 방법 : 테이블의 에코드 건수나 선택도 등을 고려하지 않고 옵티마이저에 내장된 우선순위에 따라 실행계획을 수립하는 방식(초기방식)

기본 데이터 처리

풀 테이블 스캔, 풀 인덱스 스캔

풀 테이블 스캔

테이블의 레코드 건수가 너무 작아서 인덱스를 통해 읽는것 보다 풀 테이블 스캔을 하는편이 더 빠를경우

WHERE 절이나 ON 절에 인덱스를 이용할 수 있는 조건이 없는 경우

인덱스 레인지 스캔을 사용할 수 있는 쿼리라도 조건 일치 레코드 건수가 너무 많은 경우

병렬 처리

MySQL 서버에서도 쿼리의 병렬 처리가 가능함

병렬처리는 하나의 쿼리를 여러 스레드가 작업을 나누어 동시에 처리하는 것을 의미

innodb_parallel_readtheads라는 시스템 변수를 이용해 하나의 쿼리를 최대 몇개의 스레드를 이용해서 처리할지 변경 할 수 있음

하지만, 병렬 처리용 스레드 개수를 아무리 늘리더라도 서버에 장작된 CPU의 코어 개수를 넘어서는 경우에는 오히려 성능이 떨어질 수도 있으니 주의

ORDER BY 처리

정렬을 처리하는 방법 : 인덱스를 이용하는 방법, 쿼리가 실행될 때 Filesort라는 별도의 처리를 이용하는 방법

인덱스를 사용하기 어려운 케이스

정렬 기준이 너무 많아서 요건별로 모두 인덱스를 생성하는 것이 불가능한 경우

GROUP BY의 결과 DISTINCT 같은 처리의 결과를 정렬해야하는 경우

임시 테이블의 결과를 다시 정렬해야 하는 경우

랜덤하게 결과 레코드를 가져와야 하는 경우

인덱스를 이용하지 않고 별도의 정렬처리를 수행했는지는 실행계획의 Extra칼럼에 Using filesort 메시지가 표시되는지 여부로 판단 가능

소트버퍼

MySQL은 정렬을 수행하기 위해 별도의 메모리 공간을 할당받아서 사용

이 메모리 공간을 소트 버퍼라고 함

정렬이 필요한 경우에만 할당, 버퍼의 크기는 정렬해야 할 레코드의 크기에 따라 가변적으로 증가, 메모리 공간은 쿼리 실행이 끝나면 반납

소트 버퍼의 크기가 256KB에서 8MB 사이에서 최적의 성능을 가짐

정렬 알고리즘

레코드를 정렬할 때 레코드 전체를 소트버퍼에 담을지 정렬기준 칼럼만 소트 버퍼에 담을지에 따라 싱글패스, 두패스 2가지 정렬 모드로 나뉨

첫번째 방식이 투 패스 정렬방식

두번째, 세번째 방식이 싱글패스 정렬방식

싱글패스 정렬방식

소트 버퍼에 정렬 기준 칼럼을 포함해 SELECT 대상이 되는 칼럼 전부를 담아서 정렬을 수행하는 정렬방식

투패스 정렬방식

정렬 대상 칼럼과 프라이머리 키 값만 소트 버퍼에 담아서 정렬을 수행하고, 정렬된 순거대로 다시 프라이머리 키로 테이블을 읽어서 SELECT할 칼럼을 가져오는 정렬방식

투패스 방식은 두번 읽어야 하기 때문에 불합리하지만, 싱글패스 방식은 이런 단점이 없음

다만, 싱글패스는 더 많은 소트 버퍼에 공간이 필요함

최신버전에서는 일반적으로 싱글패스 정렬방식을 주로 사용함

싱글패스는 정렬대상 레코드의 크기나 건수가 작은 경우 빠른 성능을 보여주고, 투패스 방식은 정렬 대상 레코드의 크기나 건수가 상당히 많은 경우 효율적임

정렬이 필요한 SELECT는 불필요한 칼럼은 가져오지 않는것이 가장 효율적인 방법

정렬 처리 방법

ORDER BY가 실행 시 정렬 방법

인덱스 정렬

조인에서 드라이빙 테이블만 정렬

조인에서 조인 결과를 임시테이블로 저장 후 정렬

인덱스 정렬

ORDER BY에 명시된 칼럼이 제일 먼저 읽는 테이블(조인이 사용된 경우 드라이빙 테이블)에 속하고, ORDER BY의 순서대로 생성된 인덱스가 있어야함

WHERE절에 첫번째로 읽는 테이블의 칼럼에 대한 조건이 있다면 그 조건과 ORDER BY는 같은 인덱스를 사용할 수 있어야 함

인덱스 정렬은 인덱스가 이미 정렬되어 있기 때문에 그대로 읽으면 댐

조인의 드라이빙 테이블만 정렬

조인이 수행되면 레코드는 몇배로 늘어나고, 크기도 커짐

때문에 조인을 실행하기 전에 첫번째 테이블에서 레코드를 정렬 후 조인을 실행하는게 정렬의 차선책

조인에서 첫번째로 읽히는 테이블(드라이빙 테이블)의 칼럼만으로 ORDER BY절을 작성해야함

임시 테이블 정렬

2개 이상의 테이블을 사용하면서 첫번째 테이블의 인덱스만 사용할 수 없을 경우 임시 테이블을 생성하여 정렬

3가지 방법중 정렬할 레코드가 가장 많기 때문에 가장 느린 정렬방법

정렬 처리 방법의 성능 비교

ORDER BY나 GROUP BY 같은 작업은 WHERE조건을 만족하는 레코드를 LIMIT건수 만큼만 가져와서 처리가 불가능함

조건을 만족하는 모든 레코드를 가져온 뒤 정렬을 수행하거나 그루핑 작업을 실행해야지만 LIMIT을 걸 수 있음

잘못된 ORDER BY, GROUP BY 때문에 쿼리가 느려지는 경우가 많음

쿼리가 처리되는 방법 : 스트리밍 처리, 버퍼링 처리

스트리밍 방식

서버쪽에서 처리할 데이터가 얼마인지에 관계없이 조건에 일치하는 레코드가 검색될 때마다 바로바로 클라이언트로 전송해주는 방식

쿼리를 요청하고 원했던 첫 레코드를 전달받고, 마지막 레코드는 언제 받을지 모르지만 상관없음

쿼리가 얼마나 많은 레코드를 조회하느냐에 상관없이 빠른 응답시간을 보장해줌

LIMIT까지 사용하면 마지막 데이터까지 받는데 시간이 단축됨

버퍼링 방식

ORDER BY, GROUP BY 처리는 쿼리의 결과가 스트리밍 되는 것을 불가능하게함

모든 레코드를 조회하고, 정렬하는동안 클라이언트는 무한 대기하기 때문에 응답속도가 느려짐

정렬처리 3가지 방법중 인덱스 정렬 방식은 스트리밍 형식의 처리방식

나머지는 버퍼링 방식

어느 테이블이 먼저 드아리빙 되어 조인되는지도 중요하지만, 어떤 정렬 방식으로 처리되는지는 더 큰 성능차이를 만듦

가능하다면 인덱스를 사용한 정렬로 유도하고, 최소한 드라이빙 테이블만 정렬해도 되는 수준으로 유도하는것도 좋은 튜닝 방법

디비스터디

JIN_Coder — Mon, 28 Aug 2023 00:07:54 +0900

트랜잭션

여러개의 변경 작업을 수행하는 쿼리가 조합됐을 때 이상이 있을경우 원래 상태로 돌아가게 해주는 기능

논이적인 작업 셋 자체가 100% 적용되거나(COMMIT을 실행했을 때) 아무것도 적용되지 않아야(ROLLBACK) 함을 보장해줌

INNODB는 쿼리 중 일부라도 오류가 발생하면 전체를 원 상태로 만든다는 트랜잭션의 원칙대로 INSERT문을 실행하기 전 상태로 그대로 복구함

MyISAM 테이블에서 발생하는 이러한 현상을 부분 업데이트라고 표현 - 부분 업데이트 현상은 테이블 데이터의 정합성을 맞추는데 상당히 어려운 문제를 만들어냄

트랜잭션은 어플리케이션 개발에서 고민해야할 문제를 줄여주는 아주 필수적인 DBMS의 기능

주의사항

트랜잭션 또한 DBMS의 커넥션과 동일하게 꼭 필요한 최소의 코드에만 적용하는것이 좋음

코드에서 트랜잭션의 범위를 최소화 하는것이 좋음

실제 트랜잭션의 시작은 5번

2,3,4 절차가 빨리 진행되도 트랜잭션에 포함 시킬 이유는 없음

8번 메일전송이나 FTP 파일 전송작업, 네트워크를 통해 원격서버와 통신하는 작업은 트랜잭션에서 제외하는 것이 좋음

5,6번은 하나의 트랜잭션으로 묶고, 7번은 단순 조회 작업이므로 트랙잭션에 포함하지 않아도됨

코드에서 데이터베이스 커넥션을 가지고 있는 범위와 트랜잭션이 활성화돼 있는 프로그램의 범위를 최소화 해야함

MySQL 엔진의 잠금

스토리지 엔진 레벨 잠금

MySQL 엔진 레벨 잠금 - 스토리지 엔지을 제외한 나머지 부분

MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미치지만, 스토리지 엔진 레벨의 잠금은 상호간의 영향을 미치지 않음

테이블 락 - 테이블 데이터 동기화

메타데이터 락 - 테이블의 구조를 잠금

네임드 락 - 사용자의 필요에 맞게 사용

글로벌 락

FLISH TABLES WITH READ LOCK 명령으로 획득

잠금 가운데 가장 범위가 큼

글로벌 락을 획득하면 다른 세션에서 SELECT를 제외한 대부분의 DDL문장이나 DML 문장을 실행하는 경우 글로벌 락이 해제 될 때까지 해당 문장이 대기상태로 남음

영향을 미치는 범위는 MySQL 서버 전체

글로벌 락은 모든 테이브레 큰영향을 미치기 때문에 웹서비스용으로 사용되는 MySQL 서버에서는 가급적 사용하징 않는것이 좋음

특정 세션에서 백업 락을 획득하면 모든 세션에서 다음과 같이 테이블의 스키마나 상요자의 인증관련 정보를 변경할 수 없음

데이터베이스 및 테이블 등 모든 객체 생성 및 변경, 삭제

REPAIR TABLE과 OPTIMIZE 명령

사용자 관리 및 비밀번호 변경

백업 락은 일반적인 테이블의 변경은 허용됨

주로 백업은 레플리카 서버에서 실행됨

MySQL 서버의 백업락은 정상적으로 복제는 실행되지만, 백업의 실패를 막기위해 DDL 명령이 실행되면 복제를 일시 중지하는 역할

테이블 락

개별 테이블 단위로 설정되는 잠금

LOCK TABLES table_name [READ|WRITE] 명령으로 특정 테이블의 락을 획득함

명시적으로 획득한 잠금은 UNLOCK TABLES명령으로 잠금을 반납(해제)

명시적인 테이블 락도 특별한 상황이 아니면 어플리케이션에서 사용할 일은 없음

묵시적인 테이블 락은 MySQL, MEMORY 테이블에 데이터를 변경하는 쿼리를 실행하면 발생함

MySQL 서버가 데이터가 변경되는 테이블에 잠금을 설정하고 데이털르 변경한 후, 즉시 잠금을 해제하는 형태로 사용

묵시적인 테이블 락은 쿼리가 실행되는 동안 자동으로 획득했다가 쿼리가완료된 후 자동 해제됨

InnoDB 테이블의 경우 스토리지 엔진 차원에서 레코드 기반의 잠금을 제공하기 때문에 단순데이터 변경 쿼리로 인해 묵시적인 테이블 락이 성정되지는 않음

테이블락이 성정되지만, 대부분의 데이터 변경(DML) 워리에서는 무시되고 스키마를 변경하는 뭐리의 경우에만 영향을 미침

네임드 락

GET_LOCK() 함수를 이용해 임의의 문자열에 대해 잠금을 설정 할 수 있음

잠금의 특징은 대상이 테이블이나 레코드 또는 AUTO_INCREMENT와 같은 데이버베이스 객체가 아님

자주 사용은 안됨

메타데이터 락

메타데이터 락은 데이터베이스 객체(테이블이나 뷰)의 이름이나 구조를 변경하는 경우에 획득하는 잠금

RENAME TABLES tb_a TO tb_b 같이 테이블의 이름을 변경하는 경우 자동으로 획득하는 잠금

실시간으로 테이블을 바꿔야 하는 요건이 배치 프로그램에서 자주 발생

RENAME TABLE 명령문에 두개의 RENAME 작업을 한꺼번에 실행하면 실제 어플리케이션에서 아주 짧지만 rank테이블이 없는 순간이 존재하여 에러 발생

에러 발생없이 변경 가능

메타데이터 잠금과 InnoDB의 트랜잭션을 동시에 사용하는 경우

테이블의 구조를 변경해야하는 경우

온라인 DDL을 사용하면 단일 스레드로 작동하기 때문에 많은 시간이 소요됨

새로운 테이블을 생성하고 최근 데이터를 여러개의 스레드로 빠르게 복사하고

나머지 데이터는 트랜잭션과 테이블 잠금, RENAME 으로 프로그램 중단없이 실행

미리 데이터를 복사 해야 잠금시간을 최소화하여 서비스에 미치는 영향을 줄일 수 있음

디비 스터디

JIN_Coder — Mon, 21 Aug 2023 04:10:54 +0900

시진엽

공간 인덱스

R-Tree 인덱스 알고리즘을 잉요해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스

R-Tree는 인덱스를 구성하는 칼럼의 값이 2차원의 공간 개념 값

구조 및 특성

GEOMETRY 타입은 나머지 3개 타입의 슈퍼 타입으로 POINT와 LINE, POLYGON 객체를 모두 저장 가능함

MBR : 해당 도형을 감싸는 최소 크기의 사각형의 의미

이 사각형들의 포함 관계를 B-Tree형태로 구현한 인덱스가 R-Tree 인덱스

최하위 레벨의 MBR은 각 도형 데이터의 MBR을 의미

최상위 레벨의 MBR은 중간 크기의 MBR

최상위 MBR은 R-Tree의 루트 노드에 저장된 정보, 차상위 그룹 MBR은 R-Tree의 브랜치 노드, 마지막으로 각 도형의 객체는 리프 노드에 저장

R-Tree 인덱스의 용도

R-Tree는 MBR 정보를 이용해 B-Tree형태로 인덱스를 구축, 공간인덱스

일반적으로 GPS 기준의 위도, 경도 좌표 저장에 주로 사용됨

전문 검색 인덱스

대표적으로 MySQL의 B-Tree인덱스는 실제 칼럼의 값이 1MB이더라도 1MB 전체의 값을 인덱스 키로 사용하는 것이 아니라 1000바이트 또는 3072바이트까지만 잘라서 인덱스 키로 사용함

전체 일치 또는 좌측 일부 일치와 같은 검색만 가능

문서의 내용 전체를 인덱스화 해서 특정 키워드가 포함된 문서를 검색하는 전문 검색에는 InnoDB나 MyISAM 스토리지 엔진에서 제공하는 일반적인 용도의 B-Tree인덱스를 사용할 수 없음

인덱스 알고리즘

전문 검색 인덱스는 문서의 키워드를 인덱싱하는 기법에 따라 크게 단어의 어근 분석과 n-gram분석 알고리즘으로 구분

불용어 처리 : 검색에서 별 가피가 없는 단어를 모두 필터링해서 제거하는 작업

어근 분석 알고리즘 : 검색어로 선정된 단어의 뿌리인 원형을 찾는 작업

한글이나 일본어는 어근 분석보다는 문자으이 형태소를 분석해서 명사랑 조사를 구분하는 기능이 더 중요한 편

Mecab을 이용해 한글 분석 다만, MySQL에 적용은 쉽지만, 완성도 높히는 작업이 어려운편

n-gram 알고리즘

MeCab을 위한 형태소 분석은 매우 전문적인 전문 검색 알고리즘이어서 리소스가 많이 필요함

이러한 단점을 보완하기 위한 방법으로 n-gram 알고리즘 도입

형태소 분석이 문장을 이해하는 알고리즘, n-gram은 단순히 키워드를 검색해내기 위한 인덱싱 알고리즘

n-gram : 본문을 무조건 몇 글자씩 잘라서 인덱싱 하는 방법

n-gram의 n은 인덱싱 할 키워드의 최소 글자 수 의미

일반적으로 2글자를 자르는 2-gram방식이 많이 사용

불용어 변경 및 삭제

n-gram의 토큰 파싱 및 불용어 처리예시로 at, io는 불용어로 등록돼어 있기 때문에 걸러짐

전문 검색 인덱스의 불용어 처리 무시

스토리지 엔진에 관계없이 MySQL의 모든 전문 검색인덱스에 대해 불용어를 완전히 제거

innodb_ft_enable_stopword 시스템 변수를 off로 설정

SET GLOBAL innodb_ft_enable_stopword = OFF;

MySQL 설정 파일(my.cnf)의 ft_stopword_file 시스템 변수에 빈 문자열을 설정

ft_stopword_file = ""

ft_stopword_file은 불용어 처리 무시도 하지만, 직접 등록도 가능함

전문 검색 인덱스의 가용성

전문 검색 인덱스를 사용하려면 2가지 조건 만족

쿼리 문장이 전문 검색을 위한 문법(MATCH … AGAINST …)을 사용
테이블이 전문 검색 대상 칼럼에 대해서 전문 인덱스 보유

함수 기반 인덱스

일반적인 인덱스는 칼럼의 값 일부 또는 전체에 대해서만 인덱스 생성이 허용됨

칼럼의 값을 변형해서 만들어진 값에 대해서 인덱스 구축시 함수 기반 인덱스 혹은 가상 칼럼 이용한 인덱스 사용

가상 칼럼을 이용한 인덱스

함수 기반 인덱스

디비스터디 8주차

JIN_Coder — Mon, 31 Jul 2023 01:09:41 +0900

디스크 읽기 방식

데이터베이스의 성능 튜닝은 디스크 I/O를 줄이느냐가 관건

하드디스크 드라이브 HDD / 솔리드 스테이트 드라이브 SSD

SSD

플래시메모리 사용 -> 데이터를 빨리 읽고 쓸수 있음

전원이 공급되지 않아도 데이터가 삭제되지 않음

HDD보다 랜덤 I/O 작업이 빠름

DBMS용 스토리지에 최적화됨

랜덤 I/O 순차 I/O

순차 I/O는 3개의 페이지(3*16KB)를 디스크에 기록하기 위해 1번의 시스템 콜을 요청

랜덤 I/O는 3개의 페이지를 디스크에 기록하기 위해 3번 시스템 콜을 요청

순차 I/O는 랜덤 I/O 보다 3배 더 빠름

디스크의 성능은 시스템 콜을 줄이고 한번에 기록하느냐에 따라 결정 됨

램덤 I/O는 여러번 시스템 콜을 요청 하기 때문에 작업 부하가 더 큼

사실 순차 I/O를 램덤 I/O로 변경하기는 쉽지 않기 때문에 램덤 I/O를 줄여주는 것이 쿼리 튜닝이라고 봄

풀테이블 스캔 : 순차 I/O

인덱스 레인지 스캔 : 랜덤 I/O

인덱스

DBMS 는 칼럼 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 삼아 인덱스를 만듦

칼럼값을 주어진 순서로 미리 정렬해서 보관함

SotedList ArrayList

ArrayList는 테이터 파일과 같은 자료구조

저장되는 순서 그대로 유지

SotedList는 DBMS의 인덱스와 같은 자료구조

저장되는 값을 항상 정렬된 상태로 유지

데이터가 저장될 때 마다 값을 정렬해야하므로 저장하는 과정이 복잡하고 느리지만, 이미 정렬돼어 있어 읽기가 빠름

INSERT, UPDATE, DELETE 처리는 조금 느리지만, SELECT는 빨리 처리 가능함

인덱스는 데이터를 관리하는 방식(알고리즘)과 중복 값의 허용 여부 등에 따라 분류됨

역할별로 구분

프라이머리 키, 보조키(세컨더리 키)로 구분

데이터 저장 방식(알고리즘)으로 구분

B-Tree, Hash 구분

데이터 중복 허용 여부 구분

유니크 인덱스, 유니크하지 않은 인덱스 구분

B-Tree 인덱스

데이터 베이스의 인덱싱 알고리즘 가운데 가장 일반적으로 사용, 가장 먼저 도입된 알고리즘, 범용적인 목적으로 사용중

DBMS는 B+-Tree, B-Tree를 사용

B-Tree의 B는 Binary이진이 아닌 Balanced 임

B-Tree는 칼럼의 원래 값을 변형시키지 않고, 인덱스 구조체 내에서는 항상 정렬된 상태로 유지

B-Tree 구조 및 특성

최상위에 하나의 루트노드가 존재, 하위에 자식노드가 붙어있는 형태, 트리구조의 가장 하위에 있는 노드를 리프노드, 중간 노드를 브랜치 노드라고 함

데이터베이스에서 인덱스와 실제 데이터가 저장된 데이터는 따로 관리, 리프노드는 항상 실제 데이터 레코드를 찾아가기 위한 주솟값을 가지고 있음

인덱스의 키 값은 모두 정렬돼 있지만, 데이터 파일의 레코드는 정렬돼 있지 않고 임의의 순서로 저장되어 있음

레코드가 삭제되어 빈공간이 생기면 그 다음의 INSERT 된 데이터는 빈공간을 재활용 하기 때문에 데이터가 INSERT 순으로 저장되지 않음

다만, InnoDB는 기본적으로 프라이머리 키 순서로 저장됨

인덱스는 테이블의 키 칼럼만 가지고 있으므로 나머지 칼럼을 읽으려면 데이터 파일에서 해당 레코드를 찾음

리프노드는 데이터 파일에 저장된 레코드의 주소를 가짐

InnoDB은 프라이머리 키가 ROWID 역할을 함

프라이머리 키를 주소처럼 사용하기 때문에 논리적인 주소를 가짐

InnoDB는 인덱스를 통해 레코드를 읽을 때 바로 데이터 파일을 읽지 못함, 프라이머리 키에 저장된 레코드를 읽고 해당 레코드를 가지고 인덱스 키를 찾음

B-Tree 인덱스 키 추가 및 삭제

테이블의 레코드를 저장하거나 변경하는 경우 인덱스 키 추가나 삭제 작업이 발생함

인덱스 키 추가

새로운 값이 B-Tree에 저장될 때 테이블에 저장 될 때 즉시 인덱스에 저장될 수도, 그렇지 않을 수 있음

B-Tree에 저장 될 때는 저장될 키 값을 이용해 B-Tree상의 적절한 위치를 검색함

저장될 위치가 결정되면 레코드의 키 값과 대상 레코드의 주소 정보를 B-Tree의 리프노드에 저장함

B-Tree는 상대적으로 쓰기 작업에 비용이 많이 듬

인덱스 키 삭제

B-Tree의 키 삭제는 간단함 해당 키 값이 저장된 B-Tree릐 리프 노드를 찾아 그냥 삭제 마크만 하면 작업 완료

삭제 마킹된 인덱스 키 공간은 방치하거나 재활용 할 수 있음

인덱스 키 변경

인덱스의 키 값은 그 값에 따라 저장 될 리프 노드의 위치가 결정되므로 B-Tree의 키 값이 변경 되는 경우 먼저 키 값을 삭제 후 다시 새로운 키 값을 추가함

인덱스 키 검색

인덱스 검색하는 작업은 B-Tree의 루트 노드부터 시작해 브랜치 노드를 거쳐 최종 리프 노드까지 이동하면서 비교 작업을 수행함 : 트리 탐색

B-Tree 인덱스를 이용한 검색은 100% 일치 또는 앞부분만 일치 하는경우 사용 가능, 부등호 비교 조건에서도 사용 가능

다만 인덱스를 구성하는 키 갚의 뒷부분은 사용 불가, 인덱스 키 값에 변형이 가해진 경우 사용 불가함(함수나 연산으로 변현된 값은 인덱스를 사용 할 수 없음)

B-Tree 인덱스 사용에 영향을 미치는 요소

인덱스를 구성하는 칼럼의 크기와 레코드의 건수, 유니크한 인덱스 키 값의 개수 등에 의해 검색이나 변경작업의 성능이 영향을 받음

인덱스 키 값의 크기

디스크에 데이터를 저장하는 가장 기본 단위 : page, Block 디스크의 모든 읽기 쓰기 작업의 최소 단위

인덱스는 페이지 단위로 관리되며, 루트, 브랜치, 리프노드를 구분한 기준이 페이지 단위임

일반적으로 DBMS의 B-Tree는 자식 노드의 개수가 가변적인 구조

자식 노드는 인덱스의 페이지 크기와 키 값의 크기에 다라 결정됨 기본은 16KB

자식노드 주소는 여러가지 복합적인 정보가 담긴 영역

하나의 인덱스 페이지(16KB)에는 16*1024/(16+12) 인 585개 저장 가능함(자식노드 585개를 가질 수 있는 B-Tree)

SELECT 쿼리가 레코드 500개를 읽는다면 인덱스 페이지 1번으로 해결 가능하지만, 1000개를 조회 한다면 2번 이상 디스크로부터 읽어야함

인덱스를 구성하는 키의 크기가 커지만, 디스크로 부터 읽어야 할 수가 늘어나고 그만큼 느려짐

B-Tree의 깊이

B-Tree의 깊이는 MySQL에서 값을 검색할 때 몇번이나 랜덤하게 디스크를 읽어야하는지와 직결되는 문제

인덱스 키 값의 크기가 커질 수록 하나의 인덱스 페이지에 담을 수 있는 인덱스 키 값의 개수가 적어지고, 같은 레코드 건수라도 B-Tree의 깊이가 깊어져서 디스크 읽기가 더 필요함

B-Tree 깊이는 최대한 작을 수록 좋음

선택도(기수성)

선택도, 기수성 같은 의미로 사용됨

인덱스 키 값 가운데 유니크한 값의 수를 의미

ex) 전체 인덱스 기 캆을 100개 인데 그중에서 유니크 키값이 10이라면 기수성은 10

중복된 값이 많아질수록 기수성은 낮아지고, 선택도는 떨어짐

선택도가 높을 수록 검색 대상이 줄어들기 때문에 그만큼 빨라짐

선택도가 좋지 않더라도 정렬이나 그루핑과 같은 작업을 위해 인덱스를 만드는것이 훨씬 나은 경우도 있음

인덱스에서 유니크한 값의 개수는 인덱스나 쿼리의 효율성에 큰 영향을 줌

읽어야 하는 레코드의 건수

인덱스를 통해 테이블의 레코드를 읽는 것은 인덱스를 거치지 않고 바로 테이블의 레코드를 읽는것보다 높은 비용이 듦

100만건 레코드 중 50만건을 읽을 때 전체 테이블 모두 읽고 50만건을 버릴지, 인덱스로 50만건만 읽을지 판단을 해야함

일반적인 DBMS의 옵티마이저는 인덱스를 통해 레코드 1건을 읽는 것은 직접 읽는 것보다 4~5배 비용이 듬

인덱스를 통해 읽어야 할 레코드가 25% 이상일 경우 그냥 테이블 전체 조회를 하는것이 더 효율적임

디비 스터디 7주차

JIN_Coder — Mon, 24 Jul 2023 03:44:49 +0900

칼럼변경

테이블 구조 변경 작업은 대부분 칼럼을 추가하더나 칼럼 타입을 변경하는 작업

ALTER TABLE 명령을 이용

칼럼추가

INPLACE 알고리즘을 사용한 온라인 DDL 처리, 마지막 칼럼 추가는 INSTANT 알고리즘으로 바로 추가 가능

테이블이 큰 경우 칼럼을 마지막에 추가하는거시 좋음

칼럼 삭제

칼럼을 삭제하는 과정은 항상 테이블 리빌드를 필요로 하기 때문에 INSTANT 알고리즘을 사용할 수 없음

항상 INPLACE 알고리즘을 이용해 칼럼 삭제 가능

칼럼 이름 및 칼럼 타입 변경

칼럼값의 저장용 공간은 칼럼의 값의 바이트 수가 255 이하인 경우 1바이트만 사용하고, 256 이상 사용시 2바이트를 사용함
칼럼 최대값 변경시 1바이트 이하테이블 리빌드가 필요없지만, 1바이트에서 2바이트로 변경시 테이블 리빌드가 필요함

인덱스 변경

전문 검색 인덱스와 공간 검색 인덱스를 제외하면 나머지 인덱스는 모두 B-Tree 자료구조를 사용함

전문 검색 인덱스와 공간 검색 인덱스는 INPLACE 알고리즘으로 인덱스 생성이 가능하지만, SHARD잠금이 필요함

B-Tree 자료구조를 사용하는 인덱스 추가는 잠금없이 온라인으로 인덱스 생성이 가능함

인덱스 조회

SHOW INDEXES

테이블의 인덱스만 표시

칼럼별로 한줄씨 표시

SHOW CREAT TABLE

테이블의 생성 구문을 그대로 보여줌

인덱스 별로 한줄로 표시 하고, 인덱스에 어떤 칼럼이 어떤 순서로 있는지 파악하기 쉬움

인덱스의 가시성 변경

인덱스를 삭제하는 작업은 ALTER DRP INDEX 로 즉시 완료 되지만, 한번 삭제된 인덱스를 새로 생성하는 것은 매우 많은 시간이 걸릴 수 있음

인덱스를 삭제했는데 다시 적용할 수 있기 때문에 INVISBLE을 이용하여 인덱스를 ON OFF 하여 확인 후 삭제하는것도 좋은 방법

근데 인덱스 차이로 왜 ROW 차이가 나는거임?

인덱스를 처음 생성 할 때는 INVISIBLE로 생성하고 부하가 낮은 시점에 VISIBLE로 변경해서 인덱스를 적용했다가
서버에 부하가 생기면 다시 INVISIBLE로 변경해서 원인을 고민하는것도 좋음

인덱스 삭제

ALTER TABLE ... DROP INDEX ... 명령으로 인덱스 삭제

테이블 변경 묶음 실행

하나의 테이블에 대해 여러가지 스키마 변경을 하는 경우 개별 ALTER TABLE 명령을 치기도 하지만, 한번에 모아서 처리 할 수 있음

한번에 처리한다면 테이블의 레코드를 한번만 풀스캔하여 2개의 인덱스를 한꺼번에 생성 할 수 있음

하나씩 변경

모아서 한번에 변경

프로세스 조회 및 강제 종료

SHOW PROCESSLIST

서버에 접속된 사용자의 목록이나 각 클라이언트 사용자가 현재 어떤 쿼리를 실행하고 있는지 알 수 있음

대부분의 프로세스 Command 칼럼이 Sleep 상태 이겠지만, 오랜시간을 잡고 있는 쿼리가 있다면 확인할 필요가 있음

KILL QUERY 1 은 쿼리만 종료하고 커넥션은 남아있음
KILL 1은 커넥션까지 종료시킴(트렌젝션이면 롤백함)

활성 트랜젝션 조회

트랜젝션이 5초 이상 활성 상태로 남아있는 프로세스만 조사하는 쿼리

170초 동안 트랜젝션이 유지 되는 중

쿼리 성능 테스트

쿼리 성능에 영향을 미치는 요소 -> 가장 큰 요소는 버퍼, 캐시

운영체제가 관리하는 캐시나 버퍼는 공용공간이기 때문에 MySQL 서버와 같은 프로그램이 종료된다고 해도 여전히 남을 수 있음

캐시나 버퍼가 없는 상태에서 테스트를 하려면 운영체제의 캐시나 버퍼를 지우고 테스트를 진행해야 함

InnoDB 스토리지 엔진이 관리하는 캐시를 버퍼 풀이라고 하며, 인덱스 페이지, 데이터 페이지 까지 캐시하며, 쓰기 작업을 위한 버퍼링 작업까지 겸해서 처리함

MySQL 서버에 포함된 키 캐시나 버퍼 풀을 초기화 하려면 MySQL 서버를 재시작 해야함

디비스터디6주차

JIN_Coder — Mon, 17 Jul 2023 01:38:45 +0900

스키마조작(DDL)

DDL(Data Definition Language) = DBMS 서버의 모든 오브젝트를 생성하거나 변경하는 쿼리

ex) 스토어드 프로시저나 함수, DB, 테이블 등을 생성하거나 변경하는 대부분의 명령

스키마를 변경하는 작업중에는 상당히 로랜시간이 걸리고 MySQL 서버에 많은 부하가 발생하기 때문에 주의 해야함

온라인 DDL
MySQL 5.5 이전 버전은 테이블의 구조가 변경되는 동안 커넥션 연결이 어려웠지만, 온라인 DDL 기능으로 스키마 변경을 하면서 커넥션 연결이 가능해짐

ALGORITHM, LOCK 옵션을 통해 어떤 모드로 스키마를 변경할 지 선택 가능

스키마 변경 알고리즘의 우선순위가 낮을수록 MySQL 서버는 스키마 변경을 위해서 더큰 잠금과 많은 작업을 필요로 하고, 부하가 발생함

INSTANT : 테이블의 데이터는 전혀 변경하지 않고, 메타 데이터만 변경하고 작업을 완료함

테이블이 가진 데이터 양과 무관하게 짧은 시간 소요

스키마 변경 도중 읽고 쓰기는 대기(시간이 짧아서 괜찮음)

LOCK 옵션 명시 할 수 없음

INPLACE : 임시테이블로 데이터를 복사하지 않고 스키마 변경을 수행함, 다만, 내부적으로 테이블 리빌드를 실행함

레코드 복사 작업은 없지만, 리빌드를 해야하기 때문에 테이블의 크기에 따라 시간 소요가 달라짐
스키마 변경 중에도 읽고 쓰기가 가능함

COPY : 변경된 스키말르 적용한 임시테이블이 생성되고, 테이블의 레코드를 모두 임시 테이블로 복사 후 최종적으로 임시 테이블을 RENAME해서 스키마 변경을 완료함

읽기만 가능함

ALGORITHM, LOCK 옵션이 명시되지 않으면, 서버가 적정한 수준의 알고리즘과 잠금 수준을 선택함

INPLACE, COPY 는 3가지 LOCK 옵션을 명시 함

ALTER TABLE 문장에 ALGORITHM, LOCK 절을 명시해서 온라인 스키마 변경의 처리 알고리즘을 강제 할 수 있음

온라인 DDL의 실패 케이스

- ALTER TABLE 명령이 장시간 실행되고, 동시에 다른 커넥션에서 DML이 많이 실행되는 경우, 온라인 변경 로그의 공간이 부족한 경우

- ALTER TABLE 명령이 실행되는 동안 ALTER TABLE 이전의 테이블 구조에서는 문제가 없었지만, 이후 테이블 구조에서 적합하지 않은 레코드가 INSERT, UPDATE 될 경우

- 스키마 변경을 위해서 필요한 잠금 수준보다 낮은 잠금 옵션이 사용된 경우

- 온라인 스키마 변경은 LOCT=NONE으로 실행된더라도 변경 작업의 처음과 마지막 과정에서 잠금이 필요한데, 잠금을 획득하지 못하고 타임아웃이 난 경우

- 디스크의 임시 디렉터리를 사용 할 때 공간이 부족한 경우

온라인 DDL 진행상황 모니터링

performance_schema 를 통해 진행상황을 모니터링 가능

데이터베이스 변경

MySQL에서 하나의 인스턴스는 1개 이상의 데이터베이스를 가질 수 있음

RDBMS는 스키마, 데이터베이스를 분리해서 관리
MySQL은 스키마, 데이터베이스가 동격(굳이 스키마를 명시하지 않음)

#데이터베이스 생성
CREATE DATABASE employees;

#데이터베이스 목록
SHOW DATABASE;

#데이터베이스 선택
USE employees;

#데이터베이스 삭제
DROP DATAVASE employees;

테이블 스페이스 변경

MySQL 서버는 테이블 별로 전용의 테이블스페이스를 사용했음

InnoDB 스토리지 엔진 시스템 테이블 스페이스만 제너럴 테이블 스페이스를 사용

제너럴 테이블스페이스는 여러테이블의 데이터를 한꺼번에 저장하는 테이블스페이스를 의미

8.0부터 사용자 테이블을 제너럴 테이블스페이스로 저장하는 기능이 추가됨

- 제너럴 테이블스페이스를 사용하면 파일 핸들러를 최소화

- 테이블 스페이스 관리에 필요한 메모리 공간을 최소화

제너럴 테이블스페이스는 테이블의 갯수가 많은 경우 유용함

테이블 생성

각 컬럼은 칼럼명 + 칼럼타입 + [타입별옵션] + [NULL 여부] + [기본값] 순서로 명시

테이블 구조 조회

SHOW CREATE TABLE, DESC

SHOW CREATE TABLE 사용히 테이블의 CREATE TABLE 문장을 표시(최초 명령X, 메타데이터 읽어서 재 작성)

칼럼의 목록과 인덱스, 외래키 정보를 동시에 보여주기 때문에 SQL을 튜닝하거나 테이블의 구조를 확인 할때 사용

DESC

DESCRIBE 약어 테이블의 칼럼 정보를 표의 형태로 보여줌

인덱스 칼럼의 순서나 외래키, 테이블 자체의 속성은 보여주지 않음

테이블 구조 변경

ALTER TABLE 사용

테이블 자체의 속성을 변경, 인덱스, 칼럼 추가 삭제 용도로 사용

테이블 리빌드 작업은 주로 레코드의 삭제가 자주 발생하는 테이블에서 데이터가 저장되지 않는 빈공간을 제거해 디스크 사용 공간을 줄이는 작업

OPTIMIZE TABLE : 테이블이 사용하는 디스크 공간의 프래그멘테이션을 최소화 하고, 테이블의 구조를 최적화 함

테이블 명 변경

RENAME TABLE 사용
테이블 이름 변경 뿐만 아니라, 다른 데이터베이스로 테이블을 이동할 때도 사용

RENAME TABLE db1table1 TO db2.tabel2

테이블 상태 조회

SHOW TABLE STATUS employees

테이블 구조 복사

CREATE TABLE temp_employees LIKE employees

구조가 같은 테이블 복사하여 생성

INSERT INTO tempemployees SELECT * FROM employees

데이터까지 복사

테이블 삭제

DROP TABLE table

레코드가 적은 테이블 삭제는 서비스 도중 실행해도 괜찮음
다만, 양이 많은 테이블 삭제시 MySQL 서버에 부하가 증가하여 다른 커넥션 쿼리 속도에 영향을 줄 수 있음(서비스 도중엔 조심히 사용)

디비 스터디 5주차

JIN_Coder — Mon, 3 Jul 2023 02:57:51 +0900

INSERT

INSERT 문장이 동시에 실행되는 경우 INSERT 문장 자체보다는 테이블의 구조가 서능에 더큰 영향을 미침

INSERT와 SELECT의 성능을 동시에 빠르게 만들 수 있는 테이블 구조는 없음(타협해야함)

고급옵션

INSERT IGNORE

INSERT ON DUPLICATE KEY UPDATE

유니크 인덱스나 프라이머리 키에 대해 중복 레코드를 어떻게 처리할지를 결정함

INSERT IGNORE

유니크 인데스나 프라이머리 키가 중복으로 존재하는 경우, 레코드의 칼럼과 테이블의 칼럼이 서로 호환이 되지 않는 경우 모두 무시하고 다음 레코드를 처리 할 수 있게 해줌

여러 레코드를 하나의 INSERT 문장으로 처리하는 경우 유용함

salaries 테이블의 프라이머리 키 : emp_no, from_date
중복 레코드가 있으면 에러 발생
하지만, IGNORE 옵션이 있다면 에러를 경고로 바꾸고 INSERT 진행함(무시함)

중복 데이터 뿐만아니라, 테이터 타입이 일치 하지 않을 경우 칼럼의 기본값이 들어감

함부로 쓰다간 의도치 않은 에러도 무시하고 INSERT 하기 때문에 주의해야함

INSERT ON DUPLICATE KEY UPDATE

IGNORE은 무시하고 인서트를 진행했지만, ON DUPLICATE KEY UPDATE는 중복이 발생하면 UPDATE 문장의 역할을 수행함

daily_statistic의 프라이머리 키 : target_date, stat_name

특정 날짜의 stat_name이 최초 저장되는 경우엔 INSERT 문이 실행되고, ON DUPLICATE KEY UPDATE 이하의 절은 실행안됨

이미 레코드가 존재한다면, ON DUPLICATE KEY UPDATE 이하의 절이 실행됨

LOAD DATA 명령 주의 사항

LOAD DATA : RDBMS에서 데이터를 빠르게 적재 할 수 있는 방법

MYSQL엔진과 스토리지 엔진의 호출횟수를 최소화 하고, 스토리지 엔진이 직접 데이터를 적재하기 때문에 일반적인 INSERT문보다 빠름

단점

단일 스레드로 실행 - 적재할 데이터 파일이 크다면 시간이 오래걸림

단일 트랜잭션으로 실행 - 언두 로그가 삭제되지 못하고 유지되어야 함(레코드를 찾는데 많은 오버헤드 발생)

LOAD DATA 문장으로 데이터 파일을 하나 말고 여러개로 준비해서 실행하는것이 좋음

테이블 복사 작업이라면, LOAD DATA보다 INSERT SELECT 를 사용해서 필요 데이터를 INSERT하는것이 좋음

성능을 위한 테이블 구조

INSERT의 성능은 쿼리 문장 보다 테이블의 구조에 의해 결정됨

대량 INSERT 성능

INSERT될 레코드들을 프라이머리 키 값 기준으로 미리 정렬해서 INSERT 문장을 구성하는것이 성능에 도움이 될 수 있음

프라이머리 키로 정렬된 경우 시간이 반으로 줄어듦

정렬이 안되면 랜덤 프라이머리 키 값을 B-tree 방식으로 메모리를 읽어서 INSERT 하기 때문에 오래걸림

테이블의 세컨더리 인덱스는 SELECT 문의 성능은 높히지만, INSERT 문의 성능은 떨어짐

백그라운드 작업의 부하를 유발하기 때문에 세컨더리 인덱스를 남용하면 성능상 안좋음

프라이머리 키 선정

InnoDB 스토리지 엔진을 사용하는 테이블의 프라이머리 키는 클러스터링 키인데,

이는 세컨더리 인덱스를 이용하는 쿼리보다 프라이머리 키를 이용하는 쿼리의 성능이 훨씬 빨라지는 효과를 냄

프라이머리 키는 INSERT, SELECT 성능에 대립되기 때문에 두가지 모두 만족하는 경우는 드물다고 함

SELECT는 거의 안하고 INSERT가 많은 테이블은 프라이머리 키를 단조증가,감소하는 패턴으로 설계함(주로 로그)

인덱스로 줄여주면 좋음

반대의 경우 인덱스를 걸어서 SELECT 잘되게 해도 큰 영향은 없음

*소량의 테이블 구조 및 쿼리에 투자 할 시간에 대용량(메인) 테이블 구조 및 쿼리에 시간을 쓰는게 현명함