이 삭제를 실행할 때 :
DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870... 39,157 개의 행을 삭제합니다. 클러스터 된 인덱스 및 기본 키인 ETLHeaderID에서 삭제 중이므로 단순해야합니다. 그러나 (실행 계획에 따르면) 361,190 행에 도달하고 다른 인덱스를 사용하는 것으로 보입니다. 테이블에는 XML 데이터 유형의 필드가 있습니다 (이 DELETE에 영향을주는 경우).
이 삭제 속도를 높이는 이유와 방법에 대한 아이디어가 있습니까?
실행 계획은 여기 : http://sharetext.org/qwDY 테이블 스키마는 여기 : http://sharetext.org/Vl9j
감사
답변:
계획의 최상위 레벨은 기본 테이블 (클러스터형 인덱스)에서 행을 제거하고 4 개의 비 클러스터형 인덱스를 유지 관리하는 것과 관련이 있습니다. 이러한 인덱스 중 두 개는 클러스터형 인덱스 삭제가 처리되는 동시에 행 단위로 유지됩니다. 아래의 녹색으로 강조 표시된 "+2 비 클러스터형 인덱스"입니다.
다른 두 개의 비 클러스터형 인덱스의 경우 옵티마이 저는 이러한 인덱스의 키를 tempdb 작업 테이블 (Eager Spool)에 저장 한 다음 스풀을 두 번 재생하고 인덱스 키를 기준으로 정렬하여 순차 액세스 패턴을 향상시키는 것이 가장 좋습니다.
마지막 작업 순서는 xmlDDL 스크립트에 포함되지 않은 기본 및 보조 인덱스 유지 관리와 관련이 있습니다.
이것에 대해 할 일이별로 없습니다. 비 클러스터형 인덱스 및 xml인덱스는 기본 테이블의 데이터와 동기화 상태를 유지해야합니다. 이러한 인덱스를 유지 관리하는 비용은 테이블에 추가 인덱스를 생성 할 때 발생하는 트레이드 오프의 일부입니다.
즉, xml인덱스는 특히 문제가 있습니다. 최적화 프로그램이이 상황에서 몇 개의 행을 사용할 수 있는지 정확하게 평가하기는 매우 어렵습니다. 실제로 xml인덱스에 대해 과대 평가 하여이 쿼리에 거의 12GB의 메모리가 부여됩니다 (런타임에는 28MB 만 사용됨).
과도한 메모리 부여의 영향을 줄이려면 더 작은 배치로 삭제를 수행 할 수 있습니다.
를 사용하여 정렬하지 않고 계획의 성능을 테스트 할 수도 있습니다 OPTION (QUERYTRACEON 8795). 이것은 문서화되지 않은 추적 플래그 이므로 개발 또는 테스트 시스템에서만 시도해야하며 프로덕션에서는 절대 사용하지 않아야합니다. 결과 계획이 훨씬 빠르면 계획 XML을 캡처하고이를 사용 하여 프로덕션 쿼리에 대한 계획 지침 을 만들 수 있습니다.
당신은 올바른 길을 가고 있습니다-XML 색인이 문제입니다. 분명히, 기본 XML 인덱스와 보조 XML 인덱스가 있습니다.
기본 테이블 (ETLHeaders)에 대해 DELETE를 수행 할 때이 테이블의 모든 인덱스에서 데이터도 삭제해야합니다. 이 오버 헤드는 특히 XML 인덱스의 경우 중요 할 수 있습니다.
오래 지속되는 색인은 보조 XML 색인 [XML_IX_ETLHeaders_Property]입니다. "관계형 테이블"의 39,157 행은 기본 XML 인덱스 [XML_IX_ETLHeaders]의 361,190 행을 나타냅니다. 보조 인덱스를 삭제하는 데 사용할 수 있으려면 해당 361k 행을 정렬해야합니다. 이 정렬 작업으로 인해 쿼리 기간이 길어집니다. 참고로, 두 xml 인덱스의 인덱스 통계는 잘 작동하지 않는 것 같습니다. 기본 xml 인덱스의 361k 행의 실제 데이터 크기는 160MB이지만 예상 데이터 크기는 거의 4TB입니다 (예, 4 TerraByte !!) .
이 쿼리 속도를 높이는 유일한 방법은 보조 XML 인덱스를 제거하는 것입니다. 데이터에 따라 XML 데이터를 관계형 테이블로 파쇄하는 것이 더 나은 옵션 일 수 있습니다.