Big Sun의 기록 Big Sun의 기록

MySQL 외래 키(Foreign Key)란?MySQL에서 외래 키(Foreign Key, FK)는 한 테이블의 컬럼이 다른 테이블의 기본 키(Primary Key) 또는 고유 키(Unique Key)를 참조하도록 설정하는 제약 조건입니다. 이를 통해 데이터 무결성을 유지하고, 테이블 간의 일관성을 보장할 수 있습니다.다만, MySQL에서는 InnoDB 스토리지 엔진에서만 외래 키를 지원하며, 성능 및 유지보수 이슈로 인해 실무에서는 외래 키를 사용하지 않는 경우도 많습니다. 실무에서 외래 키를 사용하지 않는 이유수동 데이터 적재 및 긴급 조치의 어려움외래 키가 설정된 경우, 부모 테이블과 자식 테이블 간의 참조 무결성이 강제됩니다.하지만 수동으로 데이터를 적재하거나 긴급 조치가 필요한 경우, 복잡한 관..

InnoDB에서는 행 수준 잠금을 지원하며 이를 공유(S) 락과 배타(X)락 이라고 부릅니다. 이번 포스팅에서는 각 락의 특징에 대해서 알아보겠습니다. 공유 락(Shared(S) Lock) 공유 락을 보유한 트랜잭션은 특정 행을 읽을 수 있습니다. 또한, 공유 락에 걸린 데이터는 읽기 연산만 가능하며 쓰기 연산은 불가능합니다. 공유 락에 걸린 데이터는 다른 트랜잭션이 공유 락밖에 휙득하지 못 하며 배타 락은 휙득할 수 없습니다. 공유 락을 사용해 조회하면 트랜잭션 내 조회한 데이터가 변경되지 않음을 보장할 수 있습니다. 아래와 같이 SELECT FOR SHARE 를 사용하여 특정 데이터로부터 공유 락을 획득할 수 있습니다.SELECT * FROM table_name WHERE id = 1 FOR SHAR..

트랜잭션의 격리 수준(isolation level)은 여러 트랜잭션이 동시에 실행될 때, 특정 트랜잭션이 다른 트랜잭션의 변경사항이나 데이터를 조회할 수 있는지를 결정하는 중요한 설정입니다. MySQL은 총 4가지 격리 수준을 제공합니다.READ UNCOMMITTEDREAD COMMITTEDREPEATABLE READSERIALIZABLE이 중에서 READ UNCOMMITTED는 커밋되지 않은 데이터를 읽는 Dirty Read 문제를 일으킬 수 있고, SERIALIZABLE은 동시 처리 성능이 낮아지는 단점 때문에 거의 사용되지 않습니다.따라서 이번 포스팅에서는 가장 자주 사용되는 READ COMMITTED와 REPEATABLE READ를 중심으로, 두 격리 수준의 차이점과 특징을 살펴보겠습니다.READ..

InnoDB 스토리지 엔진은 레코드 기반의 잠금 기능을 제공합니다. 이 덕분에 MyISAM 보다 뛰어난 동시성 처리를 제공합니다.또한, 잠금 정보가 상당히 작은 공간에서 관리되기 때문에 레코드 락이 페이지 락 또는 테이블 락으로 레벨업되지 않는 특징이 있습니다. InnoDB 스토리지 엔진에서는 레코드 락, 갭락, 넥스트 키락을 제공합니다. 이번 포스팅에서는 레코드 락과 갭 락 그리고 넥스트 키 락에 관해 다뤄보겠습니다. 레코드 락(Record Lock) 일반적으로 레코드 락(record lock)은 테이블의 특정 레코드를 잠그는 기능으로 이해됩니다.그러나 MySQL의 레코드 락은 테이블의 레코드를 직접 잠그는 것이 아니라, 인덱스의 레코드를 잠급니다.이 개념을 이해하기 위해 특정 레코드를 수정하는 상황을..

MVCC는 일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능입니다. Multi Version Concurrency Control(MVCC)을 직역하면 '다중 버전 동시성 제어'입니다. 이 표현에서 유추할 수 있는 것은 'MVCC는 여러 버전이 존재하며, 동시성 제어와 관련이 있다'는 점입니다.  하나 이상의 버전이 존재한다?하나의 레코드에 여러개의 버전이 동시에 관리됨을 의미합니다. 여러개의 버전이 왜 필요할까?(READ_COMMITTED 격리 수준을 전제로)한 레코드를 수정 중일 때, 해당 레코드를 조회하는 요청이 들어오면, 아직 수정 내용이 커밋되지 않았으므로 수정 전의 데이터를 조회해야 합니다.또한, 하나의 트랜잭션에서 레코드를 수정한 뒤 다른 작업 중 에러가 발생하면 기존 데이..

인덱스는 "색인," 즉 책의 목차와 유사한 개념입니다. 목차의 특징을 통해 인덱스의 성질을 추론할 수 있습니다.빠른 검색: 목차는 원하는 정보를 빠르게 찾도록 돕습니다. 인덱스도 데이터를 빠르게 검색할 수 있도록 설계되어 있습니다.참조 구조: 목차는 각 항목이 책의 특정 페이지와 연결되어 있습니다. 인덱스 역시 데이터와 해당 위치를 연결하는 참조 구조를 가지고 있습니다.정렬: 목차는 항목이 순서대로 정렬되어 있어 탐색이 용이합니다. 인덱스 또한 정렬된 상태를 유지해 효율적인 검색을 지원합니다.결론적으로, 인덱스는 정보를 빠르게 찾기 위해 설계된 구조로, 참조 구조를 통해 데이터를 연결하며 정렬된 상태를 유지한다는 특징을 가지고 있습니다. 인덱스 구조 인덱스는 정보를 빠르게 찾기 위함입니다. 그렇다면 인덱..

인덱스를 잘 이용하려면 당연히 인덱스가 어떻게 실제 레코드를 읽어내는 지를 알아야한다. 이번 포스팅에서는 MySQL이 인덱스를 이용하는 대표적인 방법을 살펴보겠습니다. 인덱스 레인지 스캔 인덱스 레인지 스캔은 검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방식이다. SELECT * FROM employees WHERE first_name BETWEEN 'Ebbe' AND 'Gad'; 위 쿼리를 실행하면, first_name이 세컨더리 인덱스이기때문에 스캔해야할 위치 검색을 위한 비교작업을 수월하게 수행할 수 있다. (아래 그림의 두꺼운 선) 세컨더리 인덱스를 이용해 스캔 시작 위치를 결정하고, 그 지점부터 필요한 방향으로 인덱스를 읽어나가고 있다. 위 사진은 리프 노드에 저장된 (인덱스 키, PK)를..

MySQL과 Spring Data JPA를 활용해 프로젝트를 진행할 때 아무 생각 없이 프라이머리 키를 AUTO_INCREMENT를 사용했었습니다. "프라이머리 키를 꼭 AUTO_INCREMENT로 해야하나" 라는 생각이 들었고, 이에 관해 공부해보니 역시 프라이머리 키는 업무적으로 중요한 값으로 설정해야하는 것 이었습니다. 다른 사람들에게 도움이 될 수 있겠다 싶어 포스팅을 작성하게 되었습니다. 페이지의 중요성페이지는 스토리지 엔진의 버퍼 풀에서 데이터를 버퍼링하는 기본 단위입니다. 또한, 디스크에 데이터를 저장하는 기본 단위이기도 합니다.페이지의 크기는 정해져 있으며 그 용량을 초과할 시에 새로운 페이지를 만들어 저장합니다. 따라서, 하나의 페이지에 얼마나 많은 정보가 포함되어 있는 지가 중요합니다...