MYSQL 테이블에 UUID를 저장하기위한 다양한 옵션과 절충점은 무엇입니까?

Question

MySQL 데이터베이스의 여러 테이블에서 클라이언트 제공 UUID를 기본 키로 사용할 계획입니다.

저는 UUID를 MySQL 데이터베이스에 저장하기위한 다양한 메커니즘을 보았지만 서로 비교하는 것은 아닙니다. 이러한 스토리지를 포함

• BINARY (16)
• CHAR (16)
• CHAR (36)
• VARCHAR (36)
• 2 × BIGINT

가

거기에 어떤 더 나은 옵션이든지 옵션을 서로 비교하는 방법 :

• 저장 용량은?
• 쿼리 오버 헤드? (인덱스 문제, 조인 등)
• 클라이언트 코드에서 값을 쉽게 삽입하고 업데이트 할 수 있습니까? (일반적으로 JPA를 통한 Java)

실행중인 MySQL 버전 또는 저장소 엔진에 따라 차이가 있습니까? 우리는 현재 5.1을 실행 중이며 InnoDB를 사용할 계획입니다. 나는 UUID를 사용하려고 시도한 실제 경험을 바탕으로 한 모든 의견을 환영합니다. 감사.

Answer 1

스마트 클라이언트 온라인/오프라인 저장소 및 데이터 동기화를 위해 UUID를 사용했으며 어느 시점에서 병합해야하는 데이터베이스에 대해 사용했습니다. 필자는 char (36) 또는 char (32) (대시 없음)을 항상 사용했습니다. varchar보다 약간의 성능 향상을 얻었으며 거의 ​​모든 데이터베이스가 char을 지원합니다. 나는 바이너리 또는 bigint를 한번도 시도한 적이 없다. 알고 있어야 할 것은 36 또는 32자를 사용하지 않으면 char가 공백으로 채워질 것입니다. 요컨대, 개체의 ID를 "테스트"하도록 설정 한 다음 단위 테스트를 작성하지 말고 데이터베이스에서 찾으십시오. ;)

Answer 2

실제로 UUID를 사용하여 설정 한 경우 이진 (16) 열에 저장하는 것이 좋습니다. 2x bigint와 같은 것은 관리하기가 매우 어려울 것입니다. 또한, 같은 기계에서 UUID의 시작이 처음부터 같고 다른 부분이 끝나기 때문에 사람들을 뒤집어 쓴다고 들었습니다. 따라서 역순으로하면 색인이 더 효율적이됩니다. .

물론 내 본능은 UUID를 사용하는 좋은 이유가 없다면 자동 증가 정수를 사용해야한다고 말합니다. 하나의 좋은 이유는 서로 다른 데이터베이스에서 고유 키를 생성하는 것입니다. 다른 옵션은 INT가 저장할 수있는 것보다 많은 레코드를 가질 계획입니다. 비록 많은 응용 프로그램이 정말 이런 것들을 필요로하지는 않지만. 키에 정수를 사용하지 않을 때 손실되는 효율성이 많을뿐 아니라 작업하기가 더 어려워집니다. 너무 길어서 입력 할 수 없으며 URL에서 전달하면 URL이 길어집니다. 따라서 UUID가 필요한 경우 UUID로 이동하십시오.하지만 멀리 떨어져 있으십시오.