주요 엔터티의 가능한 특성을 포함하는 여러 조회 테이블이있는 데이터베이스를 설계하고 있습니다. 자동 증분 정수가 아닌 4 또는 5 문자 키를 사용하여 이러한 조회 값을 식별하여 이러한 속성 ID를 기본 테이블에 저장하면 임의의 숫자가 아닌 의미있는 값을 볼 수 있습니다.
문자 필드를 정수가 아닌 기본 키로 사용하면 성능에 어떤 영향을 미칩니 까?
중요한 경우 MySQL을 사용하고 있습니다.
[편집]
이 조회 테이블에는 새 레코드가 자주 추가되지 않습니다. 수동으로 유지 관리되며 문자 기반 키도 수동으로 생성됩니다. 예를 들면 다음과 같습니다.
CUISINES
ID Description
----- --------------
CHNSE Chinese
ITALN Italian
MXICN Mexican
답변:
엔진에 따라 다릅니다. 일반적인 지혜는 읽기가 저렴하고 여기에서 몇 바이트이며 중소 규모 데이터베이스의 성능에 큰 영향을 미치지 않는다는 것입니다.
더 중요한 것은 기본 키를 사용할 용도에 따라 다릅니다. 정수 직렬은 사용 및 구현이 간단하다는 장점이 있습니다. 또한 직렬화 방법의 특정 구현에 따라 대부분의 데이터베이스가 일련 번호를 즉시 가져 오는 대신 고정 된 위치에 저장하기 때문에 빠르게 파생 할 수 있다는 이점 Select max(ID)+1 from foo이 있습니다.
문제는 다음과 같습니다. 5 자 키는 어떻게 귀하와 응용 프로그램에 "의미있는 가치"를 제공합니까? 이 값은 어떻게 생성되며 증가하는 일련 번호를 찾는 것보다 다소 시간이 걸립니다. 작은 정수의 공간이 일부 정수로 저장되어 있지만 대부분의 시스템은이 공간 절약을 무시합니다.
"키"를 사용할 수 없기 때문에 문자 구성표 에 자동 엔진 이 없어야한다는 것을 제외하고는 성능에 영향을주지 않습니다 . 특정 도메인의 경우 인공 키를 사용하지 말고 중국어, 일본어 및 태국어를 키 이름으로 사용하십시오. 가능한 모든 응용 프로그램에 대해 고유성을 보장 할 수는 없지만, 스코프에서는 무시 무시하고 강제적 인 5 자 약어 대신 사용하는 것이 훨씬 합리적입니다. 수백만 개의 튜플에 도달 할 때까지 성능에 큰 영향을 미치지 않습니다.
또는 특정 지역 요리 (광동어, 사천, 시칠리아, 움 브리아, 칼라브리아, 유 카테 칸, 오 악사 칸 등)가 아닌 원산지별로 추적하는 경우 항상 ISO 3166 코드를 사용할 수 있습니다 .
10,000 개의 레시피를 가지고 있다면 5 자 및 20 자 키의 차이가 더해지지 않습니까?
공간이 싸다 . OLAP 작업을 수행하는 10,000,000 개의 레시피를 이야기 할 때는 아마도 가능합니다. 10k 레시피로 150k의 공간을보고 있습니다.
그러나 다시, 그것은 달려 있습니다. 수백만 개의 레코드가 있고 조인을 수행하는 경우이 사소한 것 (구체화 된보기로)에 대한 조회를 비정규 화하는 것이 좋습니다. 모든 실제적인 목적을 위해, 5 개의 문자 키와 가변 길이 키 사이의 현대 기계에서 상대 결합 효율은 매우 유사합니다. 행복하게도, 우리는 많은 CPU와 많은 디스크의 세계에 살고 있습니다. 불쾌한 것은 문자별로 비교하기보다는 조인 및 쿼리 비 효율성 이 너무 많습니다 . 그 말로 항상 테스트하십시오 .
이 수준의 P & T는 데이터베이스에 의존하기 때문에 일반화가 매우 어렵습니다. 데이터베이스의 두 가지 샘플 모델을 빌드하고 예상 레코드 수로 채우고 어느 것이 더 빠른지 확인하십시오. 내 경험상, 문자 길이는 좋은 인덱스, 좋은 메모리 구성 및 기타 중요한 성능 조정 요소와 비교하여 큰 차이를 만들지 않습니다.
실제 질문은 DB 쿼리 성능이 애플리케이션 (데이터 크기)에 중요한지 여부입니다. 쿼리에 마이크로 초가 걸리는 경우 Int키 를 사용하여 해당 마이크로 초를 몇 분만 절약 해도 가독성 / 유지 보수 불이익이 발생하지 않습니다. 그러나 쿼리에 몇 분이 걸리면 몇 분을 절약하면 키를 아낄 가치가 있습니다 Int.
아래는 정수가 쿼리 시간을 (전체 쿼리 시간의 백분율로) 절약 할 수 있다고 생각하지만 SkySpark 설립자는 나보다 더 잘 설명 할 수 있습니다 . 전체 공개, 고용주는 SkySpark에 DB를 사용하기 위해 많은 돈을 지불하고 더 나은 / 빠른 것을 구축하려고합니다.
조회 테이블에 대한 링크 (관계)가있는 많은 순차 데이터 (로그 파일, 시계열, 분석, 텍스트 또는 음성 코 도라)가있는 경우 @에도 불구하고 스토리지 공간이 쿼리 속도에 중요하다는 것을 알 수 있습니다. 방법 Ballsun - 스탠튼의 정확한 분석 싼 공간은 $입니다. 대부분의 쿼리 시간 (순차적 데이터의 경우)은 디스크를 읽는 데 소비되므로 시간 측면에서 전체 쿼리 시간의 백분율로 공간이 저렴 하지 않습니다 . 따라서 RDB가 모든 외래 키 (관련 레코드에 대한 키)를 자동으로 효율적으로 압축 / 압축 해제하지 않으면 Int정보 단위당 디스크 공간 (및 읽기 속도) 측면에서 가장 효율적인 모든 키를 원할 것 입니다. 내용 (엔트로피). MySql의 FYI MyISAM은 제한 을 둡니다.압축 된 데이터 행으로 수행 할 수있는 작업 (읽기 전용) 즉 , 대부분의 DB 정수 필드에 대한 최소 크기 제한이 낮으므로 자동으로 증가 된 정수 는 이론적으로 가능한 한 많이 압축됩니다 . 그리고 그 압축은 다음없이 제공됩니다.
Django 와 같은 인기 있고 효율적인 ORM이 기본적으로 PK에 대해 자동 증가 정수를 사용하는 이유와 다른 SO 질문 이 같은 결론을 내린 이유 가 있습니다.