내 테이블에서 게시물 및 코멘트를 저장하는 테이블에서 자동 증가 PK를 사용합니다.
PK를 HTTP 클라이언트에 노출하고 싶지 않지만 API 구현에서 내부적으로 사용하여 빠른 조회를 수행합니다.자동 증가를위한 대체 필드 PK
사용자가 ID로 게시물을 검색하려고 할 때 테이블에 대체 고유 키가 있어야합니다. 이 필드의 유형으로 사용할 가장 좋은 (가장 일반적인) 방법은 무엇일까?
나에게 가장 명백한 것은 UUID 또는 GUID를 사용하는 것입니다.
성능을 위해이 대신 임의의 숫자 키를 생성하는 간단한 방법이 있는지 궁금합니다.
이 상황에 가장 적합한 방법은 무엇입니까?
MySQL에는 RFC 4122에 설명 된대로 버전 1 인 128 비트 UUID를 생성하고 UUID 형식의 사용자 정의에 따라 대시가있는 16 진수 문자열로 반환하는 기능이 있습니다.
https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid
진정한 UUID는 공간과 시간에 전 세계적으로 고유하기위한 것입니다. 중앙 집중적 인 고유성 검증없이 고유 한 값을 생성하기 위해 분산 된 독립 서버 세트가 필요하지 않으면 병목 현상이 발생할 수 있으므로 일반적으로 과도합니다.
또한 MySQL에는 64 비트 숫자 값을 생성하는 UUID_SHORT() 함수가 있습니다. 이것은 RFC에 부합하지 않지만 귀하의 경우에 유용 할 수 있습니다.
https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid-short
는 UUID_SHORT() 구현에 대한 설명을 읽고. 상위 비트는 드물게 변경되고 하위 비트는 단순하게 단조롭게 증가하기 때문에 무작위 UUID 값을 인덱스에 삽입하여 발생하는 성능 및 조각화 문제를 피할 수 있습니다.UWID_SHORT 값은 UNHEX()을 사용하지 않고도 BIGINT UNSIGNED에 적합합니다.
'UUID'와'GUID'는 숫자이므로 숫자입니다. 무엇이든 "최고의"절대적 해결책은 없습니다. 왜'GUID' (v4)가 효과가 없을까요? – zerkms
@zerkms 그것은 나를 위해 일할 수 있습니다. 하지만 여기에 언급 된대로 성능에 대해 조금 걱정되었습니다. https://rclayton.silvrback.com/do-you-really-need-a-uuid-guid – Trace
당신은 PK로 사용하지 않을 것입니다. 실적 단락이 귀하와 관련이 있는지 확신하지 못합니다 (그리고 100 % 정확함을 확신 할 수 없습니다). – zerkms