SQL Server에서 외래 키가 자동으로 인덱싱됩니까?
다음 SQL 문은 Table1.Table1Column에 인덱스를 자동으로 생성합니까, 아니면 명시 적으로 생성해야합니까?
데이터베이스 엔진은 SQL Server 2000입니다.
CREATE TABLE [Table1] (
. . .
CONSTRAINT [FK_Table1_Table2] FOREIGN KEY
(
[Table1Column]
) REFERENCES [Table2] (
[Table2ID]
)
)
SQL Server는 외래 키에 대한 인덱스를 자동으로 생성하지 않습니다. 또한 MSDN에서 :
FOREIGN KEY 제약 조건은 다른 테이블의 PRIMARY KEY 제약 조건에만 연결될 필요가 없습니다. 다른 테이블에서 UNIQUE 제약 조건의 열을 참조하도록 정의 할 수도 있습니다. FOREIGN KEY 제약 조건은 null 값을 포함 할 수 있습니다. 그러나 복합 FOREIGN KEY 제약 조건의 열에 null 값이 포함 된 경우 FOREIGN KEY 제약 조건을 구성하는 모든 값의 확인은 건너 뜁니다. 복합 FOREIGN KEY 제약 조건의 모든 값이 확인되도록하려면 참여하는 모든 열에 NOT NULL을 지정하십시오.
Mike의 질문을 읽으면서 그는 FK Constraint가 FK가있는 테이블 (Table1)의 FK 열에 인덱스를 생성할지 여부를 묻습니다. 대답은 일반적으로 아니오입니다. (제약의 목적 상),이 작업을 수행 할 필요가 없습니다. 반면에 제약 조건의 "TARGET"으로 정의 된 열은 참조 된 테이블에서 고유 인덱스 여야합니다. 또는 대체 키. (고유 인덱스) 또는 Create Constraint 문구가 실패합니다.
(편집 : 아래 주석을 명시 적으로 처리하기 위해 추가됨-) 특히, 외래 키 제약 조건이있는 데이터 일관성을 제공 할 때. 인덱스는 FK 측의 행 삭제에 대해서만 DRI 제약 조건의 성능에 영향을 줄 수 있습니다. 제약 조건을 사용할 때 삽입 또는 업데이트 중에 프로세서는 FK 값을 알고 있으며 PK 쪽에서 참조 된 테이블에 행이 있는지 확인해야합니다. 이미 색인이 있습니다. PK 측에서 행을 삭제할 때 FK 측에 행이 없는지 확인해야합니다. 이 경우 색인이 약간 도움이 될 수 있습니다. 그러나 이것은 일반적인 시나리오가 아닙니다.
그 외에 특정 유형의 쿼리에서는 쿼리 프로세서가 해당 외래 키 열을 사용하는 조인의 다 측면에서 레코드를 찾아야하는 경우입니다. 해당 외래 키에 인덱스가 있으면 조인 성능 이 향상됩니다. 그러나이 조건은 외래 키 제약 조건의 존재가 아니라 조인 쿼리에서 FK 열을 사용하는 것에 고유합니다. 조인의 다른 쪽이 PK인지 아니면 다른 임의의 열인지는 중요하지 않습니다. 또한 해당 FK 열을 기준으로 쿼리 결과를 필터링하거나 정렬해야하는 경우 인덱스가 도움이됩니다. 다시 말하지만 이것은 해당 열에 대한 외래 키 제약 조건과 관련이 없습니다.
아니요, 열에 외래 키를 만들어도 해당 열에 인덱스가 자동으로 만들어지지는 않습니다. 외래 키 열을 인덱싱하지 못하면 다음 각 상황에서 테이블 스캔이 발생합니다.
- 참조 된 (상위) 테이블에서 레코드가 삭제 될 때마다.
- 두 테이블이 외래 키에서 조인 될 때마다.
- FK 열이 업데이트 될 때마다.
이 예제 스키마에서 :
CREATE TABLE MasterOrder (
MasterOrderID INT PRIMARY KEY)
CREATE TABLE OrderDetail(
OrderDetailID INT,
MasterOrderID INT FOREIGN KEY REFERENCES MasterOrder(MasterOrderID)
)
OrderDetail은 MasterOrder 테이블에서 레코드가 삭제 될 때마다 스캔됩니다. OrderMaster 및 OrderDetail에 가입 할 때마다 전체 OrderDetail 테이블도 스캔됩니다.
SELECT ..
FROM
MasterOrder ord
LEFT JOIN OrderDetail det
ON det.MasterOrderID = ord.MasterOrderID
WHERE ord.OrderMasterID = @OrderMasterID
일반적으로 외래 키를 인덱싱하지 않는 것은 규칙보다 훨씬 더 예외입니다.
외래 키를 인덱싱하지 않는 경우는 사용되지 않는 경우입니다. 이로 인해 서버의 오버 헤드가 불필요하게됩니다. 유형 테이블은 때때로이 범주에 속할 수 있습니다. 예는 다음과 같습니다.
CREATE TABLE CarType (
CarTypeID INT PRIMARY KEY,
CarTypeName VARCHAR(25)
)
INSERT CarType .. VALUES(1,'SEDAN')
INSERT CarType .. VALUES(2,'COUP')
INSERT CarType .. VALUES(3,'CONVERTABLE')
CREATE TABLE CarInventory (
CarInventoryID INT,
CarTypeID INT FOREIGN KEY REFERENCES CarType(CarTypeID)
)
Making the general assumption that the CarType.CarTypeID field is never going to be updated and deleting records would be almost never, the server overhead of maintaing an index on CarInventory.CarTypeID would be unnecessary if CarInventory was never searched by CarTypeID.
참고URL : https://stackoverflow.com/questions/278982/are-foreign-keys-indexed-automatically-in-sql-server
'code' 카테고리의 다른 글
Rails 3 마이그레이션에서 열거 형 열을 어떻게 설명합니까? (0) | 2020.11.21 |
---|---|
Angular.js 및 HTML5 날짜 입력 값 — Firefox에서 날짜 입력에 읽을 수있는 날짜 값을 표시하는 방법은 무엇입니까? (0) | 2020.11.21 |
PowerShell에서 $ Error를 지우는 방법은 무엇입니까? (0) | 2020.11.21 |
부모 / 조상 요소에 대한 CSS 부정 의사 클래스 : not () (0) | 2020.11.21 |
PHP에서 system (), exec () 및 shell_exec ()의 차이점은 무엇입니까? (0) | 2020.11.21 |