모든 값이 36 자일 때 char 대 varchar로 인덱스 조회가 눈에 띄게 빠릅니다.

모든 테이블의 기본 키에 해시 기반 생성 ID를 사용하는 레거시 스키마 (면책 조항!)가 있습니다 (많음). 이러한 ID의 예는 다음과 같습니다.

922475bb-ad93-43ee-9487-d2671b886479

이 방법을 변경할 가능성은 없지만 인덱스 액세스 성능이 떨어집니다. 옆이 될 수있는 이유의 수많은 설정, 적은 최적 비해 보였다 내가 발견 한 것이 있습니다 - 길이가 정확히 36 문자가있는 모든 많은 테이블의 모든 ID 값에도 불구하고이 열 유형입니다 varchar(36), 하지 char(36) .

고정 길이에 열 유형을 변경하는 것 char(36)청약 중요한 인덱스 페이지 등 당 항목 수의 아주 작은 증가를 넘어, 인덱스 성능 향상?

즉, postgres는 가변 길이 유형보다 고정 길이 유형을 처리 할 때 훨씬 빠르게 수행됩니까?

최소한의 스토리지 절약은 언급하지 마십시오. 컬럼 변경에 필요한 수술과 비교할 필요는 없습니다.

아니요. 전혀 이득이 없습니다 . 매뉴얼에는 다음과 같이 명시되어 있습니다 .

팁 : 공백으로 채워진 유형을 사용할 때 스토리지 공간이 증가하고 길이가 제한된 컬럼에 저장할 때 길이를 확인하기 위해 몇 가지 추가 CPU주기를 제외하고는 이 세 가지 유형간에 성능 차이가 없습니다 . character(n)일부 다른 데이터베이스 시스템에서는 성능 이점이 있지만 PostgreSQL에서는 그러한 이점이 없습니다. 실제로 character(n)추가 스토리지 비용으로 인해 3 개 중 가장 느립니다. 대부분의 상황에서 text 또는 character varying대신 사용해야합니다 .

대담한 강조 광산.

char(n)매우 구식이며 쓸모없는 유형입니다. 와 붙어 있습니다 varchar(n). 길이를 적용 할 필요가 varchar없거나 text조금 더 빠를 수 있습니다. 차이를 측정 할 수 없습니다.

모든 문자열의 길이가 36 자 정확히 경우 또한, 존재하지 아니 어느 쪽이든, 심지어 소문자 하나를 저장하는 저장. 디스크와 RAM의 크기는 정확히 동일합니다. pg_column_size()(표현식과 식에서) 테스트 할 수 있습니다 .

관련 :

• 문자열을 저장하기 위해 데이터 유형 "text"를 사용하는 데 단점이 있습니까?

다른 옵션을 요청하지 않았지만 두 가지를 언급하겠습니다.

1. COLLATION- "C"데이터 정렬로 DB를 실행하지 않는 한 . 데이터 정렬은 종종 간과되고 아마도 비쌉니다. 문자열은 자연 언어에서 의미가없는 것 같으므로 COLLATION규칙 을 따르는 데 아무런 의미가 없습니다 . 관련 :

   • "가장 최근에 해당하는 행"을 효율적으로 얻는 방법은 무엇입니까?
   • 인덱스를 사용하지 않는 함수 내에서 EXECUTE?

   COLLATE "C"성능에 미치는 영향을 비교하는 광범위한 벤치 마크 :

   • 조인 된 테이블의 열에 의한 느린 쿼리 순서

2. 분명히 UUID 입니다. 문자열이 의심스럽게 UUID (32 개의 16 진수 + 4 개의 구분자)처럼 보입니다. 실제 이러한 저장하는 것이 훨씬 더 효율적이 될 것이다uuid빠르게 여러 가지 방법입니다 만 차지하는 데이터 형식, 16 바이트 - 반대 (37) 에 대한 RAM 바이트 중 하나char(36)또는varchar(36)(만 32 정의 문자, 구분 기호없이 저장) 또는 (33) 디스크의 바이트. 그러나 정렬 패딩 은대부분의 경우 40 바이트를초래합니다.)COLLATION는uuid데이터 유형과도관련이 없습니다.

   SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

   도움이 될 수 있습니다 (마지막 장).

   • 텍스트 표현의 16 진수를 10 진수로 변환

   참조 :

   • varchar (n)의 오버 헤드는 무엇입니까?
   • MD5 필드에 가장 적합한 데이터 유형은 무엇입니까?