외부 키는 SQL Server에서 자동으로 인덱싱됩니까?
다음 SQL 문은 자동으로 표 1에 인덱스를 생성합니까?표 1열 또는 열을 명시적으로 생성해야 합니까?
데이터베이스 엔진은 SQL Server 2000입니다.
CREATE TABLE [Table1] (
. . .
CONSTRAINT [FK_Table1_Table2] FOREIGN KEY
(
[Table1Column]
) REFERENCES [Table2] (
[Table2ID]
)
)
SQL Server는 외부 키에 인덱스를 자동으로 만들지 않습니다.MSDN에서도:
외부 키 제약 조건은 다른 테이블의 기본 키 제약 조건에만 연결할 필요가 없습니다. 다른 테이블의 고유 제약 조건 열을 참조하도록 정의할 수도 있습니다.FORIENAL KEY 제약 조건은 null 값을 포함할 수 있지만 복합 FORIENAL KEY 제약 조건의 열에 Null 값이 포함된 경우 FORIENAL KEY 제약 조건을 구성하는 모든 값의 확인을 건너뜁니다.복합 FORIENT KEY 제약 조건의 모든 값을 확인하려면 모든 참여 열에 NOT NULL을 지정합니다.
Mike의 질문을 읽었을 때, 그는 FK 제약 조건이 FK가 있는 표(표 1)의 FK 열에 인덱스를 만들 것인지 묻고 있습니다.대답은 "아니오"이며 일반적으로 (제약 조건의 목적을 위해) 이 작업을 수행할 필요가 없습니다. 반면 제약 조건의 "TARGET"으로 정의된 열은 참조된 테이블에서 기본 키 또는 대체 키 중 하나의 고유 인덱스여야 합니다.(고유 인덱스) 또는 Create Constraint 문이 실패합니다.
(EDIT: 아래 설명을 명시적으로 처리하기 위해 추가됨 -) 특히 외부 키 제약 조건이 있는 데이터 일관성을 제공하는 경우 인덱스는 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)
)
주문 세부 정보는 마스터 주문 테이블에서 레코드를 삭제할 때마다 검색됩니다.또한 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)
)
일반적으로 차량 유형을 가정합니다.CarTypeID 필드는 절대 업데이트되지 않으며 레코드를 삭제하는 것은 거의 불가능합니다. 즉, CarInventory에서 인덱스를 유지 관리하는 서버 오버헤드입니다.CarType에서 CarInventory를 검색하지 않은 경우 CarTypeID가 필요하지 않습니다.신분증.
다음 문서에 따르면: https://learn.microsoft.com/en-us/sql/relational-databases/tables/primary-and-foreign-key-constraints?view=sql-server-ver16#indexes-on-foreign-key-constraints
기본 키 제약 조건과 달리 외부 키 제약 조건을 만들면 해당 인덱스가 자동으로 생성되지 않습니다.
언급URL : https://stackoverflow.com/questions/278982/are-foreign-keys-indexed-automatically-in-sql-server
'programing' 카테고리의 다른 글
vuex + typescript + 네임스페이스 모듈: 다른 모듈 상태 액세스 (0) | 2023.07.15 |
---|---|
WooCommerce Subscriptions - 제품에 이미 활성 가입자가 있는지 확인합니다. (0) | 2023.07.15 |
날짜 사이의 Excel SUMIF (0) | 2023.07.15 |
정보 손실 없이 인자를 정수\숫자로 변환하는 방법은 무엇입니까? (0) | 2023.07.15 |
순수한 TypeScript 프로젝트에서 "ReferenceError: exports is not defined"를 수정하는 방법은 무엇입니까? (0) | 2023.07.15 |