성능 문제를 일으키는 데이터베이스 디자인 문제가 발생했습니다.

Question

다중 모듈 C#/SQL Server 기반 응용 프로그램을 설계하고 있습니다. 내 디자인은 KeyTypeValues이라는 테이블에서 모든 일반 조회 값을 보유하는 것입니다. 이 표는 어떤 유형의 데이터인지 정의하는 KeyTypes과 관련이 있습니다. 샘플 데이터

Id KeyTypeName   KeyTypeDescription 
-- -----------   ------------------ 
1 RES_MFGS   Resource Manufacturers 
2 RES_OWNERSHIP_TYPES Resource Ownership Types 
... 

oms.KeyTypeValues ​​:

oms.KeyTypes 
------------ 
Id   INT NOT NULL IDENTITY(1,1) PRIMARY KEY 
KeyTypeName VARCHAR(40) NOT NULL 
... 

oms.KeyTypeValues 
----------------- 
Id     INT NOT NULL IDENTITY(1,1) PRIMARY KEY 
KeyTypeId   INT NOT NULL (FOREIGN KEY to oms.KeyTypes Id) 
KeyTypeValueMeaning VARCHAR(80) NOT NULL 
... 

oms.KeyTypes 샘플 데이터 : 예를 들어

는

Id KeyTypeId KeyTypeValueMeaning 
-- --------- ------------------- 
1 1   Ford 
2 1   Chevrolet 
3 2   Owned 
4 2   Leased 
... 

그래서 아이디어는 내가 필요가 없다는 것입니다 별도의 Manufacturers, OwnershipType, Model 등의 테이블을 만들려면 이 값 이외의 값에 대한 추가 정보가 필요하지 않습니다. 현재 약 88 개가 이미 정의되어 있으며 설계가 잘 작동합니다.

res.ResourceItems 테이블에서 조인 할 때 성능 문제를 일으키는 문제점 쿼리를 작성하고 있습니다. 다른 조회를 위해 KeyTypeValues 테이블에 6 번 테이블을 결합해야합니다. ResourceItems 정의의

는

부 :

나는 내 문제 키 유형 ( RES_OWNERSHIP_TYPES)을 제거하면

res.ResourceItems 
----------------- 
Id    INT NOT NULL IDENTITY(1,1) PRIMARY KEY 
OwnsershipTypeId INT NOT NULL 
ManufacturerId INT NOT NULL 
... 

, 나는 활짝 열려 실행할 수 있으며이 약 17 초 70 + 열이 다시 ~ 112,000 행을 가져옵니다. 성능은 환상적이지는 않지만 9 개의 추가 테이블에 합류해야한다고 생각하면 받아 들일 수 있습니다. 그러나 조인을 추가하여 RES_OWNERSHIP_TYPES을 검색하면 실행 시간이 45 초로 이동합니다. RES_OWNERSHIP_TYPES 키 유형에는이 시점에서 가능한 값이 3 개뿐이고 oms.KeyTypeValues에는 약 3,000 개의 총 레코드 만 있습니다. 시간이 지남에 따라 시스템이 더 많이 추가 될 때마다 천천히 성장할 것입니다.

소유자 유형을 꺼내고 대신를 만드는 것이 소유권 유형이 더 이상 없으므로이를 처리하는보다 효율적인 방법이라고 생각합니다. 그러나 나는 그러한 극적인 성능이있는 전반적인 디자인에 관심이 있습니다.

모든 ID 값에 대해 res.ResourceItems에서 oms.KeyTypeValues까지의 외래 키 관계가 있습니다. oms.KeyTypeValues.Id 열에 Non-Unique, Non-Clustered 인덱스 설정도 있습니다. 나는 파편을 제거하기 위해 그것들을 재건했다.

테스트로서, 나는 내 res 스키마에 별도의 KeyTypes 및 KeyTypeValues 테이블을 생성 단지와 RES_OWNERSHIP_TYPES 값을로드하고 결합하고, 실행 시간은 약 17 초 되돌아 갔다. 차라리 내 목적을 이겨내고 더 큰 문제에 반창고를 씌우는 것처럼 보이기 때문에 나는 이것을 수행하지 않을 것입니다.

내가 왜 그렇게 큰 히트가 있었는지 알 수 없으며 누군가가 내가 간과 할 수있는 것에 대해 통찰력을 가지기를 바랍니다. 필요한 경우 더 많은 데이터베이스 설계를 공유하게되어 기쁩니다.

Answer 1

3 개의 레코드가있는 테이블에 조인을 추가하면 성능에 큰 영향을 주므로 해당 조인을 추가하면 쿼리 계획이 크게 변경됩니다.

시도하는 빠르고 더러운 것은 sp_updatestats을 한 번 실행하여 문제가 해결되는지 확인하는 것입니다. 이렇게하면 SQL Server가 모든 테이블과 인덱스에 대한 통계를 업데이트하고 쿼리 계획을 통해 더 나은 선택을하도록 할 수 있습니다.

보다 완벽한 솔루션은 을 이해하기 위해 두 가지 유사 검색어의 실행 계획을 비교하는 것이고 성능에 문제가있는 것입니다. 이렇게하면 성능을 향상시키는 방법을 알 수 있습니다. 테이블을 제거하고 코드 전용 열거 형을 사용하는 것은 권장하지 않습니다. 일이 올바르게 작동하면 추가 테이블에 참여할 때 눈에 띄는 성능 차이가 없어야합니다.

Answer 2

나는보다 빠른 JOIN

그러나 우리는 실제 데이터와 돈이없는 작동 sub-query, 대신 조회 테이블 (조회 테이블이기 때문에) 작은 때때로 경우 JOIN

의 sub-query를 사용하는 것이 좋습니다 실행 계획이 없으므로 다른 답변을 제안으로 시도하고 어떤 답변이 사용자에게 도움이되는지 확인해야합니다.

이 방법으로 문제가 해결되지 않으면 참조 필드 외에 참조 필드에도 색인을 추가하십시오.

나는 디자인이 좋지 않다고 생각하지 않습니다. 여러 시스템에서 이러한 조회 테이블을 보았습니다.