mysql innodb 사용시 pk 선정에 대한 고려사항
1. innodb 의 특성
- pk컬럼의 값으로 데이터가 정렬되어 저장된다.
- 세컨더리 인덱스에서 rowid 같은 물리적 주소를 사용하지 않고 pk 값을 참조함.
이런한 특성으로 pk를 사용한 range 검색에 유리하지만, pk변경이 발생하게 되면 레코드의 재배치,
인덱스 재구성 과정이 발생하여 성능에 매우 불리함. 세컨더리 인덱스가 많을경우 pk 가 길면 저장공간이 커짐.
- PK가 크면 전체적인 인덱스 크기도 커진다. 작은 PK는 메모리 사용을 줄이고 인덱스 성능을 향상시킴.
2. innodb 에서 pk 선정
우선순위 : 본질 식별자 > auto increment > no pk
1) 본질식별자로 pk 설정하는 경우
- 업무적으로 의미 있는 칼럼을 PK로 설정하면 쿼리 조건에 자주 사용되어 성능에 유리
- 순차적이고 업데이트가 거의 발생하지 않는 값인지 확인이 필요.
- 단일키 구성이 어려울 경우, 복합키로 구성도 고려할수 있다.
2) auto increment 로 pk 를 설정하는 경우 (인조식별자, surrogate key)
장점)
- 삽입 성능이 우수함. 정수형 데이터로 인덱스 크기가 작고 효율적.
- 자동으로 증가하는 값으로 중복을 피할 수 있어 고유성이 보장됨.
단점)
- 업무적 의미가 없어 쿼리 조건으로 사용되기 어려운 경우가 많음.
- 보안 측면에서 취약할 수 있다. 키 값이 예측 가능해 SQL injection 공격에 노출 가능성
- 분산 환경에서 사용이 어렵다. 여러 데이터베이스에서 키 값 중복 문제가 발생할 수 있다
로그성 테이블 같은 조회보다 insert 가 주 목적인 경우면 나쁘지 않다.
3) pk 없이 테이블을 생성하는 경우
innodb 는 내부적으로 인조식별자를 만든다. 이것은 시스템 내부적으로만 쓰이게 되어 성능상 이점이 없다.
=> 최소 auto increment 를 사용하는 것이 낫다.
'생계 > MySQL' 카테고리의 다른 글
mysql dump 및 load 수행하는 여러가지 방법 (0) | 2024.11.10 |
---|---|
mysql replication 상태 반복 체크 (0) | 2024.10.18 |
mysql 복제 비교 replication , aurora (1) | 2024.09.16 |
mysql 로그들 bin relay general slow log (0) | 2024.09.15 |
DBeaver 시스템 오브젝트 보기 information_schema (0) | 2024.01.16 |