VARCHAR 열을 색인화하는 것이 좋습니다 / 접근법입니까?

우리는 PostgreSQL v8.2.3을 사용하고 있습니다.

EMPLOYEE 및 EMAILLIST 와 관련된 테이블이 있습니다 .

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 개의 테이블은 EMPLOYEE.EMAIL1 또는 EMPLOYEE.EMAIL2에 일치하는 항목이없는 경우 해당 행이 리턴되는 방식으로 결합됩니다.

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

열 EMAIL이다 VARCHAR (256) 의 EMAILLIST테이블 인덱스이다. 이제 응답 시간은 14 초입니다.

테이블 수 통계 : 현재 EMPLOYEE는 165,018 개의 레코드를 보유하고 EMAILLIST는 1,810,228 개의 레코드를 보유하고 있으며 두 테이블 모두 향후에 증가 할 것으로 예상됩니다.

1. VARCHAR 열을 색인화하는 것이 좋습니다 / 접근법입니까? 이 질문은 응용 프로그램에서 VARCHAR 열을 인덱싱하지 않았기 때문에 즉시 생각납니다. 이에 대한 전문가의 조언 / 제안은 높이 평가됩니다.
2. 이 현재 쿼리 및 인덱스를 사용하면 14 초의 응답 시간이 합리적이거나 추가 튜닝을위한 범위가 있습니까? 이러한 종류의 테이블 크기 및 응답 시간을 기반으로 한 다른 사용자의 실시간 경험 / 의견은 무엇입니까?

참고 : 실제 요구 사항 / 사용 사례는 여기 에 자세히 설명되어 있습니다 .

varchar 열을 기반으로 쿼리를 수행하려는 경우 varchar 열을 인덱싱하는 데 아무런 문제가 없습니다. 그러나 일부 색인에는 제한이 있으며 단일 필드에서 색인을 생성 할 수있는 양에 제한이 있습니다. 예를 들어 무제한의 텍스트를 포함 할 수있는 열을 색인 할 수 없습니다. 그러나 문제없이 varchar (256)에 대한 인덱스를 수행 할 수 있어야합니다. 사용해보고 쿼리 성능의 향상을 분석하여 도움이되는지 확인하십시오.

varchar 열을 인덱싱하는 데 문제가 없습니다.

문제가 될 수있는 곳은 varchar 열을 10 억 행 테이블의 FK로 사용하는 경우입니다. 그런 다음 PK 및 FK에 대한 대리 키가 있지만 자연 varchar 키에 대한 고유 제한 / 인덱스가 여전히 필요합니다.

테이블이 매우 작으며 성능이 OR 절과 관련 될 수 있습니다. 불행히도 쿼리를 구성하는 방법에 관계없이 동일한 문제가 적용됩니다 (PostgresSQL에 익숙하지 않아 미안합니다)

쿼리의 "OR e2.email IS NULL"부분을 제거하고 실행 속도를 확인하십시오. 더 빨리 실행되면 "모두 연합"으로 더 빨리 실행할 수 있습니다.