개발 노트

Full Text Index 배경 일반적으로 mysql에서 문자열을 검색할 때, 텍스트 내용이 어마어마한 경우에는 성능이 저하됩니다. 이를 해결하기 위해 Full Text Index가 만들어졌습니다. Full Text Index은 첫 글자 뿐 아니라 중간의 단어나 문자응로도 인덱스를 생성해 주기 때문에 순식간에 검색 결과를 얻을 수 있습니다. Full Text Index 인덱싱 Stop-word parser 공백이나 Tab, 문장 기호 또는 사용자가 정의한 문자열을 기준으로 토큰을 나누는 기법입니다. ex) 아빠가 방에 들어갔다. -> 아빠가/방에/들어갔다 N-gram parser n-gram 기법을 이용하여 할당한 토큰의 크기 n만큼씩 데이터를 인덱스로 파싱해두었다가 사용하는 기법입니다. ex) 아빠가..

Timestamp 1970-01-01 00:00:01 ~ 2038-01-19 08:44:07 까지의 데이터만 지원 4byte 크기가 필요 TIMEZONE에 따라 시간 변화 가능 데이터가 숫자형으로 저장 Datetime 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 사이의 데이터 지원 5byte + 3byte(초단위를 저장하기 위함) 크기가 필요 TIMEZONE에 따라 시간 변화 불가 데이터가 문자형으로 저장

char 고정 크기의 문자열을 담는 데이터 타입 경우에 따라 데이터가 낭비될 수 있음 크기가 고정이라 남는 부분에 대한 연산이 필요 없기에 조회시 속도가 varchar에 비해 빠른 속도를 보임 varchar 가변 크기의 문자열을 담는 데이터 타입 인덱스 생성이 가능 text 가변 크기의 문자열을 담는 데이터 타입 최대 65535 글자를 담을 수 있지만 크기 지정 불가 길이를 표현하기 위한 2byte의 공간복잡도 존재 인덱스를 제한적으로 생성 가능. 부분 prefix 인덱스만 가능 text를 사용하는 이유 varchar 타입은 한 레코드에 65535 글자만 적재할 수 있음(한 레코드 모든 글자의 합 - InnoDB의 레코드 크기 제한사항) text 타입은 위와 같은 제한이 없고 다른 속성들과 별도로 다른 ..

문법 순서 SELECT > FROM > WHERE > GROUP BY > HAVING > ORDER BY 실행 순서 FROM > ON > JOIN > WHERE > GROUP BY > HAVING > SELECT > DISTINCT > ORDER BY FROM: 조회 테이블 확인 ON: 조인 조건 확인 JOIN: 테이블 조인 WHERE: 데이터 추출 조건 확인 GROUP BY: 특정 컬럼 그룹핑 HAVING: 그룹핑 이후 데이터 추출 조건 SELECT: 데이터 추출 DISTINCT: 중복 제거 ORDER BY: 데이터 순서 정렬

Row Level Lock Shared Lock Shared Lock은 특정 Row를 읽을 때 사용되는 Lock 입니다. Shared Lock끼리는 동시에 접근이 가능합니다. 즉 하나의 row를 여러 트랜잭션이 동시에 읽을 수 있다는 것입니다. 하지만 Shared Lock이 설정된 Row에 Exclusive Lock을 사용할 수는 없습니다. 즉, 특정 Row를 누가 읽고 있음으로 Shared Lock이 설정되어 있는데, 다른 사용자가 그 데이터에 쓰기 작업을 하기 위해 Exclusive Lock을 걸 수 없다는 의미입니다. 일반적인 Select 쿼리는 Lock을 사용하지 않고 DB를 읽어 들입니다. 하지만 Select ... FOR Share 등 일부 Select 쿼리는 특정 Row를 읽을 때 InnoD..

TRUNCATE 전체 데이터를 한 번에 삭제하는 방식 최초 생성되었을 당시의 STORAGE만 남기고 데이터가 담겨있던 STORAGE는 RELEASE됨 TRUNCATE 명령어를 실행하면 처음 테이블을 CREATE한 상태와 동일 자동 COMMIT이 되기 때문에 삭제된 데이터는 복구 불가 DELETE WHERE절을 사용하여 테입르에 있는 데이터를 하나하나 석택하여 제거하는 방법 WHERE절을 사용하지 않고 테이블의 모든 데이터를 삭제하더라도 내부적으로는 한줄 한줄 일일이 제거함 처리 속도가 느린 편이고 성능에 좋지 않은 영향을 줄 수 있음 COMMIT 명령어가 실행되기 전이라면 ROLLBACK 명령어를 통해 삭제된 데이터를 복구할 수 있음 데이터를 삭제하더라도 데이터가 담겨있던 STORAGE는 RELEASE ..

JSON 지원 일반적으로 text 컬럼에 json 데이터를 넣으면 나중에 검색할 때 어려움이 많습니다. 데이터를 모두 읽어서 다시 파싱하고, 특정 항목을 찾아서 테이블의 별도 컬럼에 저장한 다음에 그 컬럼으로 인덱스 생성하는 등 작업할게 많습니다. 하지만 이제 native json 데이터 타입 컬럼에 넣어두면 이 모든 작업을 간편하게 진행할 수 있습니다. 쿼리 성능 향상 임시 테이블 엔진 변경 기존에는 sub query를 사용할 때 만들어지는 임시 테이블이 MyISAM이었습니다. 그런데 MYSQL 5.7부터는 INNODB 엔진으로 바꾸면서 성능이 더 좋아졌습니다. UNION ALL 수정 더 이상 UNION ALL을 진행할 때, 임시 테이블을 생성하지 않습니다. Optimizer Hint 수정 Optimi..

Clustering Factor란 Clustering Factor란 Index의 테이블에 대한 정렬 정도를 의미합니다. 정렬 정도를 측정하기 위해 DB는 Index를 scan하는 동안 방문하게 되는 Table의 데이터 블록의 갯수로 나타냅니다. 이는 Clustering Factor가 높아지면 읽어들이는 Data Block의 갯수가 많아지기 때문에 Physical Read가 높게 나온다는 것을 의미합니다. Physical Read는 성능과 밀접한 관련이 있기 때문에 Clustering Factor를 최소화하는 것이 튜닝의 중요 요소 중 하나라고 할 수 있습니다. Good Clustering Factor Good Clustering Factor란 Index 순서와 Table의 순서가 거의 완벽하게 일치하는 ..

Optimizer의 개념 Optimizer란 SQL 개발자가 SQL을 작성하고 실행할 때, Optimizer는 SQL을 어떻게 실행할 것인지를 계획합니다. Optimizer는 SQL 실행 계획을 수립하고 SQL을 실행하는 DBMS의 소프트웨어입니다. 동일한 결과가 나오는 SQL도 어떻게 실행하느냐에 따라 설능이 달라집니다. Optimizer 특징 Optimizer는 데이터 딕셔너리에 있는 오브젝트 통계, 시스템 통계 등의 정보를 사용해서 예상되는 비용을 산정합니다. Optimizer는 여러 개의 실행 계획 중에서 최저 비용을 가지고 있는 계획을 선택해서 SQL을 실행합니다. Optimizer의 필요성 개발자가 작성한 SQL문을 어떻게 실행하느냐에 따라 성능이 달라집니다. Optimizer가 비효율적으로 ..

Index Range Scan B-tree 인덱스의 가장 일반적이고 정상적인 형태의 액세스 방식입니다. 인덱스 루트에서 리프 블록까지 수직적 탐색을 하고 필요한 범위만큼 수평정 탐색하는 스캔 방식입니다. Index Range Scan을 하려면 선두 컬럼을 가공하지 않은 상태로 조건절에 사용해야 합니다. Index Full Scan Index Full Scan은 수직적 탐색 없이 인덱스 리프 블록 처음부터 끝까지 수평적으로 탐색하는 방식입니다. 데이터 검색을 위한 최적의 인덱스가 없을 때 차선으로 선택됩니다. 만약, 인덱스 선두 컬럼이 조건절에 없으면 옵티마이저는 먼저 Table Full Scan 방식을 고려합니다. 그런데 대용량 테이블인 경우에 Table Full Scan 방식이 부담된다면 옵티마이저는 ..