Смотря на план запроса вы можете встретить Probe Residual в операторе Hash Match. Это означает что какие-то предикаты могут быть очень «плохими», даже если на первый взгляд они выглядят хорошо (даже когда используется Seek).
Давайте рассмотрим само соединение (join). JOIN — это 2 потока данных, которые сравнивают строки. Результат сравнения должен удовлетворять условиям соединения, которые указано в ON (предикаты). Предикаты могут быть очень разнообразными.
Сравним:
SELECT P.Name, D.OrderQty, D.UnitPrice FROM Production.ProductArchive2013 AS P INNER JOIN Sales.SalesOrderDetail AS D ON (p.ProductID = D.ProductID) SELECT P.Name, D.OrderQty, D.UnitPrice FROM Production.ProductArchive2014 AS P INNER JOIN Sales.SalesOrderDetail AS D ON (p.ProductID = D.ProductID) GO
Оба запроса одинаковы за исключением таблиц, но первый имеет меньшую стоимость. В чём же разница?
Без понимания что такое Probe Residual вы будете думать что планы одинаковые, но на самом деле это не так. Давайте посмотрим на описание оператора Hash Match:
Что это?
В данном случае Probe Residual вызывается неявным преобразованием, которое не отображается нигде в плане запроса. Так же неявное преобразование не получается найти и в XML плане запроса:
Изучив структуру и тип данных таблиц, обнаружилось что таблицы ProductArchive2014 и ProductArchive2013 отличаются типами данных столбца ProductID (BIGINT против INT):
CREATE TABLE [Production].[ProductArchive2014]( [ProductID] [bigint] NOT NULL, … CREATE TABLE [Production].[ProductArchive2013]( [ProductID] [int] NOT NULL, … CREATE TABLE [Sales].[SalesOrderDetail]( … [ProductID] [int] NOT NULL, …
Если мы приведёт столбцы ProductID к одному типу данных, то сможем ускорить наш проблемный запрос.
Probe Residual помогает нам обнаружить неявное преобразование и не только.
Если вы хотите проверить ваш XML план на проблемы, то, можете воспользоваться данной ссылкой.
Вырезки из статей:
Probe Residual when you have a Hash Match – a hidden cost in execution plans
What’s a probe residual?