외래 키에 인덱스를 만들어야합니까?

외래 키에 인덱스를 만들어야합니까?

---

나는 테이블 A과 테이블이 B있습니다. 의 기본 키 에 A대한 외래 키가 있습니다.BBB_ID

어떤 이유로 (합법적 인 이유가 있음을 알고 있음) 키 에서이 두 테이블을 조인 할 때 인덱스를 사용하지 않습니다.

A.B_ID외래 키의 존재 여부 에 따라 인덱스를 별도로 만들어야 합니까?

---

외래 키 제약 조건만으로는 인덱스를 제공하지 않으며 인덱스를 제공해야합니다.

---

외래 키를 생성해도 A.B_ID에 인덱스가 자동으로 생성되지는 않습니다. 따라서 일반적으로 쿼리 성능 관점에서 A.B_ID에 별도의 인덱스를 만드는 것이 합리적입니다.

B에서 행을 삭제 한 경우 A.B_ID를 색인화해야합니다. 그렇지 않으면, Oracle은 B에서 행을 삭제할 때마다 A에서 전체 테이블 스캔을 수행하여 분리 된 레코드가 없는지 확인해야합니다 (Oracle 버전에 따라 추가 잠금 영향이있을 수 있지만 줄어 듭니다) 최신 Oracle 버전에서).

---

추가 정보 : Oracle은 (a) 제약 조건을 적용 할 필요가 없으며 (b) 경우에 따라 필요하지 않기 때문에 고유 제약 조건과 마찬가지로 인덱스를 자동으로 만들지 않습니다.

그러나 대부분 의 경우 인덱스를 작성하려고합니다 (실제로 Oracle Apex에는 "인덱싱되지 않은 외래 키"에 대한 보고서가 있습니다).

응용 프로그램이 부모 테이블에서 행을 삭제하거나 PK 값 (보다 드물게)을 업데이트해야 할 때마다 인덱스가 없으면 DML이 전체 자식 테이블을 잠그기 때문에 문제가 발생합니다.

일반적으로 인덱스를 추가 하지 않기로 선택한 경우 FK가 열 도메인 (예 : 상태 코드 테이블)을 정의하는 "정적 데이터"테이블에있는 경우 (부모 테이블에서 업데이트 및 삭제가 수행되지 않음) 응용 프로그램에서 직접. 그러나 열에 인덱스를 추가하면 응용 프로그램의 중요한 쿼리에 이점이있는 경우 인덱스가 여전히 좋습니다.

---

SQL Server는 외래 키 열에 자동으로 인덱스를 넣지 않았습니다 .이 도시 신화의 배경과 역사에 대한 Kim Tripp의 훌륭한 블로그 게시물 을 확인하십시오.

일반적으로 외래 키 열을 인덱싱하는 것이 좋습니다. 따라서 각 FK 열을 인덱스로 백업하는 것이 좋습니다. 반드시 하나의 열에 만있는 것은 아닙니다. FK 열이 첫 번째 열인 두 개 또는 세 개의 열에 인덱스를 만드는 것이 좋습니다. 시나리오와 데이터에 따라 다릅니다.

---

성능상의 이유로 인덱스를 작성해야합니다. 기본 테이블의 삭제 작업 (삭제할 레코드가 사용되지 않았는지 확인) 및 일반적으로 외래 키가 관련된 조인에 사용됩니다. 로그를 만들지 않는 테이블은 거의 없지만 인덱스가 필요하지는 않지만 아마도이 경우 외래 키 제약 조건이 필요하지 않을 수 있습니다.

그러나

외래 키에서 이미 자동으로 인덱스를 생성하는 데이터베이스가 있습니다. Jet Engine (Microsoft Access 파일) Firebird MySQL

확실히

SQL Server 오라클

하지 않습니다

---

성능과 관련된 모든 요소와 마찬가지로 많은 요소에 의존하며 예를 들어 매우 높은 액티비티 환경에서는 인덱스 유지 관리가 허용되지 않을 수 있습니다.

여기서 가장 두드러진 것은 선택 성인 것 같습니다. 인덱스의 값이 많이 복제되면 인덱스를 삭제하고 (가능한 경우) 테이블 스캔을 허용하는 성능이 향상 될 수 있습니다.

참고 URL : https://stackoverflow.com/questions/4127206/do-i-need-to-create-indexes-on-foreign-keys