[TIL] 23/07/03 Primary Key의 데이터 타입 INT VS BIGINT

오늘 한 것 + 오늘 배운 것

---

 

int (4바이트, 32비트)

: 부호가 있는 경우에는 -2,147,483,648에서 2,147,483,647 사이의 값 (약 21억), 부호가 없는 경우에는 0에서 4,294,967,295 (약 43억)사이의 값을 저장할 수 있다. 

 

bigint (8바이트, 64비트)

: 부호가 있는 경우에는 -9,223,372,036,854,775,808에서 9,223,372,036,854,775,807 (약 922경) 사이의 값, 부호가 없는 경우에는 0에서 18,446,744,073,709,551,615 사이의 값을 저장할 수 있다.

 

PK의 데이터 타입을 설정할 때는 저장하려는 데이터의 크기와 범위를 고려하여 선택해야 한다. 현재 테이블의 PK는 통일 되어 있지 않고, int, bigint를 섞어서 쓰고 있는 상태다.

INT: options, menu_option, category, user

BIGINT: cart, order_history, order, order_detail

 

데이터의 증가가 빠를 것으로 예상되는 테이블과, 느릴 것으로 예상되는 테이블의 PK 데이터 타입을 다르게 설정했다.

하지만... cart, order 등등 테이블의 데이터가 43억개 이상으로 늘어날 일이 있을까? 

중규모 프로젝트인 만큼, 공간을 낭비하지 않고 조금 더 효율적으로 서버를 운영하려면 BIGINT를 INT로 바꾸는게 낫겠다는 판단을 했다.

 

[면접] id를 왜..bigint..?

현재 진행 중인 프로젝트의 이용자는 특정되어 있는 만큼, 대규모의 확장성은 기대할 수 없다고 생각한다.

그렇기 때문에 bigint를 쓰는 것은 자원의 낭비가 될 수도 있다는 것이 결론이다.

 

 

아래는 왜 하필 int일까 검색하다가 찾은 좋은 글. 인덱스 공부도 추가로 하는 게 좋을 듯하다.

 

우리는 PK 에 왜 int 형 데이터를 고집할까