MySql Auto_INCREMENT vs UUID 장단점 비교 및 결과

도입

프로젝트를 진행하며 Table의 pk값을 어떻게 설정해야 할까 고민이 생겼다.

대표적으로 Auto_INCREMENT 또는 UUID를 사용하는 방법이 있다.

이 방법은 각각 장단점이 존재하기 때문에 비교해보면서 내 프로젝트에 도입할 방법을 생각해보도록 하겠다.

 

비교

Auto_INCREMENT

 

설명 : 자동 증가 정수 기반의 키

 

장점 

1. 삽입 성능이 좋다. 기본적으로 정수형 데이터이기 때문에 인덱스의 크기가 작고 효율이 좋아 데이터베이스 성능을 향상 시킬 수 있다.

2. 고유성이 있다. 자동으로 고유한 기본 키 값을 할당하기 때문에 새로운 레코드가 삽입될 때마다 자동으로 증가하는 값을 사용하여 중복을 피할 수 있다.

 

단점

1. 분산 환경에서 지원이 어렵다. 만약 여러 데이터베이스로 write작업을 하는 경우 각각의 데이터베이스에서 키값이 증가되기 때문에 키 값이 중복되는 문제가 생길 수 있다.

2. 키를 예측하기 쉬워진다. 키값이 예측될 수 있다는 점은 SQL injection 공격에도 취약해질 수 있고, 고객수 등을 알아가는 등 보안상 문제가 생길 가능성이 있다.

 

UUID

 

설명 : 128비트 데이터로 100% 중복되지 않는다고 할 수는 없지만 실질적으로 중복되는 값이 없는 키

 

장점

1. 고유성이 있다. 중복될 가능성이 사실상 없이 고유한 키값을 생성할 수 있다.

2. 분산 환경에서 사용하기 용이하다. 독립적으로 생성되기 때문에 여러 데이터베이스에서 생성을 하여도 중복되지 않는 키를 생성한다.

3. 보안측면에서 유리하다. 일반적인 정수형태의 키와 달리 예측가능성이 현저히 낮기 때문에 보안면에서 우수하다.

 

단점

1. 인덱스 크기가 증가한다. CHAR(32)의 필드를 pk로 사용하게 되는데, 일반적으로 사용하는 BIGINT(8바이트)보다 4배 크다.

cf)이를 개선하기 위해 BINARY(16)형태로 변환해서 저장하면 크기를 절반으로 줄일 수 있다. 

2. 성능이 떨어진다. 서버에서 uuid를 생성해야 하므로 insert시 시간이 더 걸린다는 단점이 있다. 또한 인덱스 재배열의 과정이 필요해서 성능면에서 부족함을 보인다.

 

결과

두 가지를 비교해본 결과 어떠한 상황에서든 정답인 방법은 없는 것 같다.

상황에 맞는 방법을 쓰면 된다고 느꼈다.

보안이 가장 중요시되고 다중 DB를 사용하는 환경이면 UUID의 사용을 고려해 보는 것도 괜찮아보였다.

하지만 내 프로젝트의 경우 단일 DB이기도 하고 성능과 메모리 측면에서 더 우수한 Auto_INCREMENT를 선택하기로 하였다.