Mysql 메 인 키 UUID 와 자체 증가 메 인 키 의 차이 및 우열 분석

머리말
이전 에는 postgresql 데이터 베 이 스 를 사용 하여 구름 에 오 른 후에 홈 키 에서 uid 로 바 뀌 었 는데 uid 가 전 세계 에서 유일 하고 편리 하 다 고 느 꼈 습 니 다.
최근 my sql 을 사용 하여 my sql 메 인 키 는 모두 자체 증가 메 인 키 를 선택 한 것 을 발견 하 였 습 니 다.왜 my sql 이 자체 증가 메 인 키 를 선택 하 는 지 자세히 비교 해 보 세 요.무엇이 다 릅 니까?
my sql 5.0 이전에 여러 master 가 복사 한 환경 이 라면 홈 키 를 사용 할 수 없습니다.중복 이 가능 하기 때 문 입 니 다.5.0 및 그 후의 버 전 은 자체 오프셋 설정 을 통 해 전체 문 제 를 해결 했다.
어떤 상황 에서 우 리 는 uid 를 사용 하고 싶 습 니까?
1.중복 을 피하 고 scale 에 편리 합 니 다.이것 이 바로 우리 가 cloud service 를 할 때 uid 를 선택 하 는 주요 원인 입 니 다.
2.입고 전 아 이 디 알 수 있 음
3.상대 적 으로 안전 하고 uid 에서 정 보 를 쉽게 얻 을 수 없 지만 증가 하면 정 보 를 노출 하기 쉽다.만약 에 한 고객 id 가 123456 이면 고객 id 가 123456 이라는 것 을 쉽게 알 수 있다.
UUID 가 뭐 가 문제 야?
1.uid 는 16 개의 바이트 가 있 는데 int(4 byte)와 bigint(8 byte)보다 더 많은 저장 공간 을 차지한다.
2.size 와 무질서 성 으로 인해 성능 문제 가 발생 할 수 있 습 니 다.
Mysql 의 uid 원리
my sql 의 innodb 저장 엔진 이 storage 를 처리 하 는 방식 은 색인 을 모 으 는 것 입 니 다.
집합 색인 이란 데이터베이스 줄 에 있 는 데이터 의 물리 적 순서 와 키 값 의 논리(색인)순서 가 같다 는 것 을 말한다.하나의 표 에는 하나의 집합 색인 만 있 을 수 있 습 니 다.왜냐하면 하나의 표 의 물리 적 순 서 는 한 가지 상황 만 있 기 때 문 입 니 다.
1.uid 를 메 인 키 로 사용 하 는 이유
(1).사실 innodb 저장 엔진 에서 증가 하 는 id 를 메 인 키 로 하 는 성능 이 가장 좋 습 니 다.저장 과 읽 기 속도 가 가장 빠 르 고 저장 공간 도 가장 작다.
(2).그러나 우리 가 실제 프로젝트 에 도착 하면 문제 가 발생 할 수 있 습 니 다.역사 데이터 시트 의 메 인 키 id 는 데이터 시트 의 id 와 중복 되 고 두 장의 자체 증가 id 를 메 인 키 로 하 는 표 가 합 쳐 질 때 id 는 반드시 충돌 할 수 있 습 니 다.그러나 각자 의 id 가 다른 표 와 연결 되 어 있다 면 조작 하기 어렵 습 니 다.
(3).UUID 를 사용 하면 생 성 된 ID 는 표 가 독립 된 것 이 아니 라 라 라 이브 러 리 가 독립 된 것 입 니 다.이후 의 데이터 조작 에 매우 좋 으 니,한 번 고생 하면 영원히 편안 해진 다 고 할 수 있다.
2.UUID 의 장단 점
단점:1.삽입 속도 에 영향 을 주 고 하 드 디스크 의 사용률 이 낮다.
2.uid 간 의 크기 가 상대 적 으로 느 려 서 조회 속도 에 영향 을 줍 니 다.
3.uid 가 공간 을 차지 합 니 다.색인 을 많이 만 들 수록 영향 이 심각 합 니 다.
장점:데이터 분할,통합 저장 이 나타 날 때 전체적인 유일 성 을 달성 할 수 있 습 니 다.
3.최 적 화 된 방안
(1).InnoDB 엔진 시트 는 B+트 리 에 기반 한 색인 조직 표 입 니 다.
(2).B+트 리:B+트 리 는 디스크 나 다른 직접 액세스 보조 장 치 를 위해 설 계 된 균형 찾기 트 리 입 니 다.B+트 리 에서 모든 기록 노드 는 버튼 값 의 크기 순 서 를 같은 층 의 잎 노드 에 저장 하고 각 잎 노드 지침 을 연결 합 니 다.
(3).InnoDB 메 인 색인:잎 노드 는 완전한 데이터 기록 을 포함 합 니 다.이런 색인 을 집합 색인 이 라 고 한다.InnoDB 의 색인 은 매우 빠 른 메 인 키 검색 성능 을 제공 합 니 다.그러나 보조 색인 에 도 메 인 키 열 이 포함 되 어 있 기 때문에 메 인 키 가 비교적 크게 정의 되면 다른 색인 도 매우 클 것 이다.표 에 많은 색인 을 정의 하려 면 홈 키 를 최소 화하 도록 노력 하 세 요.InnoDB 는 색인 을 압축 하지 않 습 니 다.
(4).색인 을 모 으 는 방식 은 메 인 키 를 누 르 는 검색 을 매우 효율 적 으로 하지만 보조 색인 검색 은 두 번 의 색인 을 검색 해 야 한다.먼저 보조 색인 을 검색 하여 메 인 키 를 얻 은 다음 에 메 인 키 로 메 인 색인 에서 검색 하여 기록 을 얻는다.
상술 한 것 을 종합 하면 얻 을 수 있다.
(1).InnoDB 표 의 데이터 기록 순서 가 B+트 리 색인 의 잎 노드 순서 와 일치 하면 이때 액세스 효율 이 가장 높 습 니 다.저장 과 조회 성능 을 위해 서 는 자체 성장 id 를 메 인 키 로 사용 해 야 합 니 다.
(2).InnoDB 의 메 인 인덱스 에 대해 데 이 터 는 메 인 키 에 따라 정렬 됩 니 다.UUID 의 무질서 성 으로 인해 InnoDB 는 엄 청 난 IO 압력 을 가 할 수 있 습 니 다.이때 UUID 를 물리 적 메 인 키 로 사용 하기에 적합 하지 않 고 논리 적 메 인 키 로 사용 할 수 있 으 며 물리 적 메 인 키 는 여전히 자체 증가 ID 를 사용 합 니 다.전역 의 유일 성 을 위해 서 는 uid 로 색인 을 만 들 거나 외부 키 를 만들어 야 합 니 다.
4.uid 를 메 인 키 로 사용 하지 않 으 려 면 다음 과 같은 팁 을 사용 하 십시오.
주종 즉 M-S 모드 라면 my sql 자체 함수 uid 를 사용 하지 않 고 유일한 메 인 키 를 만 드 는 것 이 좋 습 니 다.메 인 시트 에서 생 성 된 uid 가 표 에서 다시 연결 하려 면 데이터 베 이 스 를 통 해 이 uid 를 찾 아야 합 니 다.데이터 베 이 스 를 한 번 더 해 야 합 니 다.또한 이 시간 차 에서 메 인 시트 는 데이터 생 성 이 있 을 가능성 이 높 기 때문에 관련 uid 에 오류 가 발생 하기 쉽 습 니 다.uid 를 사용 하려 면 자바 에서 생 성 된 후 DB 에 직접 저장 할 수 있 습 니 다.이때 주종 의 uid 는 같 습 니 다!
추가:mysql 의 uid()메 인 키 반복
1.my sql 의 uid()메 인 키 반복
my sql 은 navicat 클 라 이언 트 를 사 용 했 습 니 다.다음 sql 을 실 행 했 습 니 다.

select replace(uuid(), '-', '') as id, u.user_id from t_user u;

그 결과 생 성 된 uid 가 중복 되 었 습 니 다.

조사 결과 navicat 의 문제 임 을 발 견 했 습 니 다.이 sql 문 구 를 다음 과 같이 조정 해 야 합 니 다.

select replace(convert(uuid() using utf8mb4), '-', ''), u.user_id from t_user u;

결 과 는 다음 과 같다.

2.다른 방안 사용:
uid 를 md5 로 다시 진행 합 니 다:

select md5(uuid()) as id, u.user_id from t_user u;

이상 은 개인 적 인 경험 이 므 로 여러분 에 게 참고 가 되 기 를 바 랍 니 다.여러분 들 도 저 희 를 많이 응원 해 주시 기 바 랍 니 다.만약 잘못 이 있 거나 완전히 고려 하지 않 은 부분 이 있다 면 아낌없이 가르침 을 주시 기 바 랍 니 다.