MariaDB PK(Primary Key) 설계 가이드

MariaDB PK 설계 가이드

 

 

PK란 데이터베이스 테이블에서 각 행을 고유하게 식별하기 위해 사용되는 열 또는 열 조합을 말한다.
PK는 데이터 무결성을 유지하는 데 중요한 역할을 하며, 테이블 설계의 기본 요소 중 하나이다.

MariaDB에서 테이블을 생성할 때 가장 중요한 건 뭘까? 바로 테이블의 Primary Key(이하 PK)를 설정하는 거다.

오늘은 MariaDB에서 PK를 설계하는 가이드에 대해 작성해 보도록 하겠다.

 

1. PK 설계 원칙

첫 번째, 고유하고 불편한 값 이용

• PK는 각 행을 고유하게 식별해야 하며, 변경되지 않는 값을 사용하는 것이 좋다.
• 자주 변할 가능성이 있는 값(예: 이메일, 전화번호 등)은 PK로 부적합하다.

두 번째, 단일 열(Single Column) PK 권장

• 복합 키(여러 열을 조합한 PK)는 가능한 피하고, 단일 열로 구성된 PK를 사용하는 것이 좋다.
• 단일 열은 더 간단하고 인덱스 관리 및 성능 최적화 측면에서 유리하다.
• 즉, PK는 단일열로 하되 필요에 따라 복합 열로 인덱스를 생성하는 게 좋다.

세 번째, 숫자형 데이터 유형 사용

• INT, BIGINT, UNSIGNED와 같은 숫자형 데이터 타입을 사용하면 검색 및 정렬 성능이 더 빠르다.
• 문자열이나 UUID는 경우에 따라 유용할 수 있지만, 성능이 떨어질 수 있으니 주의해야 한다.

네 번째, 자동 증가(Auto Increment) 활용

• PK로 고유한 값이 필요할 때 AUTO_INCREMENT를 활용하면 간단히 고유한 숫자 값을 생성할 수 있다.
• 예시

CREATE TABLE user
(
    USER_ID	INT	AUTO_INCREMENT PRIMARY KEY,
    USER_NM	VARCHAR(20),
    EMAIL	VARCHAR(200)
);

 

 

 

 

 

다섯째, 너무 긴 PK 피하기

• PK는 인덱스에 포함되므로, 길이가 길수록 인덱스 크기가 커지고 성능이 저하될 수 있다.
• 예를 들어, 32자 UUID보다는 숫자형 PK가 더 효율적이다.

 

2. 복합 키 설계가 필요한 경우

복합 키 필요성

• 복합 키는 단일 열로 고유성을 보장할 수 없는 경우에만 사용해야 한다.
• 예를 들어, 코드그룹값과 코드값의 조합으로 고유성을 정의할 수 있다.

CREATE TABLE code
(
    CODE_GROUP_ID	        VARCHAR(8),
    CODE			VARCHAR(8)
    CODE_NM			VARCHAR(100),
    PRIMARY KEY (CODE_GROUP_ID, CODE)
);

 

 

 

복합 키 설계 시 주의점

• 복합 키는 외래 키(FK)로 참조될 때 성능이 저하될 수 있으므로 주의해야 한다.
• 너무 많은 열을 조합하면 인덱스 크기가 커지고, 성능 문제가 발생할 수 있다.

 

3. MariaDB에서 PK 설계 시 자주 사용되는 패턴

자동 증가 PK

• 가장 일반적으로 사용되는 패턴으로, 간단하고 고유한 값 생성이 가능하다.

CREATE TABLE orders
(
    ORDER_ID    BIGINT  UNSIGNED    AUTO_INCREMENT  PRIMARY KEY,
    USER_ID     INT,
    PRICE       DECIMAL(10, 2)
);

 

 

고윳값을 사용한 PK

• PK의 값은 고유해야 한다.
• 테이블의 목적상 필요한 데이터 중 고유한 값으로 PK를 설정한다.
• 예) 주민등록번호, 사번, 주문번호(일정한 패턴을 가진, 예 : 연월일_순번(25011200001)) 등

복합 키와 인덱스 조합

• 복합 키를 사용하는 경우에도 자주 조회되는 열에 대해 개별 인덱스를 추가하는 것이 좋습니다.

CREATE TABLE orders_detail
(
    ORDER_ID        BIGINT,
    ORDER_DETAIL_ID BIGINT,
    GOODS_CD        VARCHAR(8),
    GOODS_NM        VARCHAR(100),
    PRIMARY KEY (ORDER_ID, ORDER_DETAIL_ID),
    INDEX IDX_orders_detail_01 (GOODS_CD)
);

 

 

4. 성능 최적화를 위한 PK 설계 팁

1. 인덱스 확인 : PK는 자동으로 인덱스가 생성되므로, 추가적인 인덱스 설정이 필요하지 않다. 다만, FK로 사용될 경우 관련 열에도 인덱스를 생성하면 성능이 향상한다.
2. 읽기와 쓰기 패턴 분석 : 데이터베이스에 대한 읽기 및 쓰기 패턴을 분석하고, PK가 성능 병목을 유발하지 않도록 설계해야 한다.
3. 데이터 분할(Sharding) : 대규모 시스템에서는 PK 설계 시 데이터를 샤딩하거나 분산 저장 방식을 고려해야 한다.
4. 정규화와 비정규화 균형 : PK 설계는 데이터 정규화와 비정규화 간의 균형을 유지해야 한다. 관계가 너무 복잡해지지 않도록 주의한다.

 

5. 잘못된 PK 설계 예시

• 변경 가능한 값은 사용하지 않는다. 예를 들어 이메일, 휴대폰번호 등은 변경 가능성이 있기에 적합하지 않다. 고유 ID나 자동증가값으로 PK를 생성하고 변경 가능성이 있는 값은 별도 열로 저장한다.
• 너무 많은 열을 복합 키로 생성하지 않는다. 이유는 PK도 인덱스를 생성하기에 인덱스 크기 증가로 인한 성능 저하기 있을 수 있다. 또 외래 키 관계의 복잡성 증가, 데이터 수정 및 관리의 어려움 등 때문이다.

 

6. 결론

• MariaDB에서 PK를 설계할 때는 고유성, 간결성, 불변성이라는 세 가지 핵심 원칙을 기억하자.
• 일반적으로 자동증가 숫자형 PK가 가장 간단하고 성능이 우수한 편이다.
• 복합 키나 UUID를 사용할 때는 신중하게 성능 영향을 분석하고, 최적화된 설계를 통해 데이터베이스 안전성과 효율성을 극대화하자.