PK에 대하여

이론상으로 int가 유리
- MySql 기준으로 inno DB storage engine로 index, data는 on-disk 구조위에 존재
- 디스크 특성상 데이터 조회시 블럭단위로 읽게되며 최소 단위가 존재한다. (inno DB → 페이지)
- 보통 이는 16kb 이며 혹시모를 상황에 대비해 1kb는 비워둔다
- B-Tree 특성
  - 1개의 페이지에 int는 3750개, char는 2500개 → int가 더 적은 page 필요
  - node balance를 맞추는 과정에서 page split (큰 비용) 발생 최소화
- 조회시 비교가 int가 간편하고 빠름
  - int : <, >, =
  - char : %something, something%
- char는 ‘ ‘ 공백도 1byte로 취급하여 ‘a’와 ‘a ‘가 다른 데이터로 인식됨
하지만 서비스와 테이블의 특성을 고려하여 병행하여 사용하는 것이 보통이다
- 문자형의 경우 중복제거를 위해 랜덤 날짜나 숫자를 붙이는 형식도 사용
- 오라클은 시퀀스 사용
- 오히려 인조키를 후순위로 생각해야한다는 의견도 존재

int (4 byte)
- bigint에 비해 10%가량 디스크 용량 절약
- 중규모의 DB는 서버 운용에 보다 효율적
- B-Tree 특성상 int가 유리
bigint (8 byte)
- 향후 업그레이드 가능성이 있으면 bigint를 쓸 것 (김영한 강사님도 이렇게 추천)
- 추후 수정이 매우 어렵다 (양도 많고 PK는 다른 테이블에서 FK로 쓰는 경우도 많음)
UUID (Universally Unique ID) (16 byte)
- java 5부터 지원 (java.util.UUID)
- 128비트 데이터로 100% 유니크하지는 않으나 충돌 가능성이 매우 낮은 키
- auto incerment는 키를 예측하기 쉬워 SQL Injection에 취약
- 분산환경에서는 UUID를 추천 (auto increment를 사용하면 충돌 가능성이 높음, Duplicate Key)
- BINARY(16) or VARCHAR
- auto increment보다 메모리 많이 사용, insert시 시간도 더 걸림
```
@Id
@GeneratedValue(generator = "uuids")
@GenericGenerator(name= "uuid2", strategy = "uuid")
private UUID id;
```