배경
약 12 개의 "테이블"에 조인 및 / 또는 왼쪽 조인하는 SQL Server 2008 R2에 대해 실행중인 쿼리가 있습니다. 데이터베이스는 5 천만 개가 넘는 테이블과 약 300 개의 서로 다른 테이블이있는 상당히 큽니다. 전국에 10 개의 창고가있는 대기업입니다. 모든웨어 하우스는 데이터베이스를 읽고 씁니다. 꽤 크고 바쁩니다.
문제가있는 쿼리는 다음과 같습니다.
select t1.something, t2.something, etc.
from Table1 t1
inner join Table2 t2 on t1.id = t2.t1id
left outer join (select * from table 3) t3 on t3.t1id = t1.t1id
[etc]...
where t1.something = 123
조인 중 하나는 상관되지 않은 하위 쿼리에 있습니다.
문제는 오늘 아침, 시스템에 대한 변경 (나 또는 팀원 모두가 알고 있음)없이 실행하는 데 일반적으로 약 2 분이 걸리고 실행하는 데 1 시간 반이 걸리는 쿼리입니다. 전혀 달렸다. 나머지 데이터베이스는 잘 작동합니다. 나는 일반적으로 실행되는 sproc 에서이 쿼리를 가져 와서 동일한 속도로 하드 코딩 된 매개 변수 변수를 사용하여 SSMS에서 실행했습니다.
이상한 점은 상관되지 않은 하위 쿼리를 가져 와서 임시 테이블에 넣은 다음 하위 쿼리 대신 해당 쿼리를 사용하면 쿼리가 제대로 실행된다는 것입니다. 또한이 코드를 쿼리 끝에 추가하면 쿼리가 훌륭하게 실행됩니다.
and t.name like '%'이 작은 실험에서 느려진 이유는 SQL의 캐시 실행 계획이 설정되는 방식 때문이라고 결론을 내 렸습니다. 조회가 약간 다르면 새로운 실행 계획을 만들어야합니다.
내 질문은 이것입니다 : 빠른 실행에 사용 된 쿼리가 갑자기 한밤중에 느리게 실행되기 시작 하고이 하나의 쿼리를 제외하고 다른 영향을받지 않으면 어떻게 문제를 해결하고 향후에 발생하지 않게합니까 ? SQL이 느리게 만들기 위해 SQL이 내부적으로 수행하는 작업을 어떻게 알 수 있습니까? (잘못된 쿼리가 실행되면 실행 계획을 얻을 수는 있지만 실행되지 않습니다. 예상되는 실행 계획이 나에게 뭔가를 줄 수 있습니까?) 이 문제가 실행 계획과 관련이있는 경우 SQL이 실제로 실행 계획이 좋은 아이디어라고 생각하지 않도록하려면 어떻게해야합니까?
또한 이것은 매개 변수 스니핑에 문제가되지 않습니다. SSMS에서 변수를 하드 코딩 할 때도 여전히 성능이 저하되기 때문에 이전에 보았지만 이것이 아닙니다.
