끔찍한 성능의 저장 프로 시저에 문제가 있습니다. 이상한 부분은 내가 절차를 실행하면 몇 시간이 걸린다는 것입니다. 프로 시저의 내용을 ssms에서 배치로 실행하면 합리적인 시간 내에 실행됩니다. 문제를 proc 내의 단일 명령문으로 좁혔습니다.실행 계획 - SQL 대 해시 대 병합 프로 시저
첫 번째 생각은 잘못된 쿼리 계획 캐시였습니다. 그러나 WITH RECOMPILE을 proc 또는 OPTION (RECOMPILE)에 추가하면 proc 내의 잘못된 명령문에 아무런 차이가 없습니다.
그래서 나는의 (실제) 실행 계획을 캡처 한 두 간부 - 보내고 절차를이 차이를 직접 문을 실행하고 발견
가 느린 저장 프로 시저 버전은 일반 SQL 반면 XML에 <Merge ManyToMany="True"> 요소가를 버전은 <Hash>입니다.
나는 왜 그것이 하나 또는 다른 것을 선택할 것인지를 결정하기위한 실행 계획에 대해 충분히 알지 못한다고 생각합니다.
두 버전 모두 동일한 데이터에서 실행되었다 - 등 :
BEGIN TRANSACTION;
exec myproc; --capture plan
ROLLBACK TRANSACTION;
BEGIN TRANSACTION
SQL Statements from procedure -- capture 2nd plan
ROLLBACK TRANSACTION
SSMS에서 직접 실행할 때 다른 것이 프로 시저 내 계획에 영향을 미칠 수있는 것들이 어떤 종류의? 누구든지 이것을 더 좁히는 방법에 대한 제안이 있습니까?
내가 얼마나이 특정 쿼리가 여기에 도움 모르겠지만,이 MERGE 문의 :
MERGE schema.UpdatableView FORUPDATE
USING
(
large select statement that's not part of the problem
) DATA
ON DATA.field = FORUPDATE
WHEN MATCHED THEN -- 50% of the cost is here
UPDATE SET
LOTS of field updates
WHEN NOT MATCHED THEN -- other 50% is here
INSERT (FIELDS)
VALUES (FIELDS
OPTION (RECOMPILE)
;
업데이트 할 수있는 뷰는 문제의 일부가 될 수 있지만, SQL 프로파일 러는 생각하지 않는 것 그래서. 뷰에있는 기본 INSERT 및 UPDATE 트리거는 명령문이 몇 시간 동안 실행되고 합리적인 시간 내에 완료 될 때까지 시작되지 않습니다.
기본 테이블의 행 수는 얼마입니까? 최근에 통계를 업데이트 한 적이 있습니까? –
대략 40-50K 행의 테이블이 업데이트되고 USING 하위 절과 거의 동일한 양이 업데이트됩니다. – Clyde
통계는 기본 테이블에 최신으로 표시됩니다. 그러나 SSMS 업데이트 할 수있는보기에 대한 통계를 표시하지 않습니다. 이게 중요합니까? 그리고 왜 이것이 저장 프로 시저와 일반 SQL 실행간에 다른 데이터를 제공합니까? – Clyde