한 프로젝트를 진행하던 중 id 타입을 왜 BIGINT를 썼는지에 대한 질문을 받았다.
프로젝트 규모가 커졌을 경우를 대비해 큰 타입을 썼다고는 답변을 했지만, 그 핑계로 너무 습관적으로 BIGINT를 써오지 않았나 반성을 하게 되었다.
그래서 id 타입에 대해 한 번 파헤쳐보겠다.
INT의 범위
INT의 범위는 4바이트이므로 -2147483648 ~ 2147483647의 범위를 갖지만, 대부분의 경우 id에 음수를 사용하지 않기 때문에 UNSIGNED 속성을 지정하면, 0 ~ 4294967295의 범위를 갖는다.
당연한 이야기겠지만, 테이블에 42억 개의 데이터가 들어갈 일이 절대 없다면 BIGINT를 쓸 필요가 없고, 심지어는 경우에 따라서 그보다 더 작은 타입들(MEDIUMINT, SMALLINT, TINYINT)을 고려할 필요가 있다.
INT형 타입들의 범위
| Type | Bytes | Signed Value | Unsigned Value |
| TINYINT | 1 | -128 ~ 127 | 0 ~ 255 |
| SMALLINT | 2 | -32768 ~ 32767 | 0 ~ 65535 |
| MEDIUMINT | 3 | -8388608 ~ 8388607 | 0 ~ 16777215 |
| INT | 4 | -2147483648 ~ 2147483647 | 0 ~ 4294967295 |
| BIGINT | 8 | -2^63 ~ 2^63 -1 | 0 ~ 2^64-1 |
INT 대신 BIGINT를 썼을 때 어떤 영향이 있을까?
1. 디스크에서 페이지를 더 많이 사용한다.
- 데이터가 램에 있지 않을 때 데이터 읽기 속도에 영향을 줄 수 있다.
- 유지관리 작업이 더 오래 걸린다(백업, 인덱스 재구축, CHECKDB)
2. 늘어난 데이터 페이지만큼 램에 더 많은 공간을 차지한다.
- 디스크에서 더 자주 읽는 비용이 발생한다.
결론
거창하게 시작했지만 결론은 간단하다. 테이블에 따라 가장 작은 데이터 타입을 쓰면 된다.
INT타입으로 충분할 것을 BIGINT로 쓴다해서 검색 속도에 엄청난 영향이 있을 것 같지는 않지만, 굳이 성능을 악화시킬 필요는 없다.
참고자료
'Database' 카테고리의 다른 글
| [MySQL] 게시글 검색(제목->내용->태그 순) (0) | 2021.12.03 |
|---|---|
| MySQL 기초 2 (0) | 2021.11.10 |
| MySQL 기초 1 (0) | 2021.11.10 |