I changed this query
SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
'009991', '009992', '009993', '009994', '009995', '009996', '009999', '900001',
'900002', '900003', '900004', '900005', '900006', '900007', '900008', '999991',
'999992', '999993', '999994', '999995'
)
GROUP BY ...
into this
SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
SELECT b.BRANCH_ID
FROM TB_BRANCH b --25 rows in total
WHERE b.START_DT = '99999999' --the result of this sub-query is fewer than list above.
)
GROUP BY ...
then performance dropped.
Why is this huge change of Execution plan happening? How can I avoid performance drop while using a sub-query in IN clause?
Best Answer
You are using a linked server to access
Table1
andTable2
.The first query is sent as is to the other server and executed there returning only the rows you want.
The second query is doing a join between a local table
TB_BRANCH
and a remote tableTable1
. To do that it fetches all rows fromTable1
and all rows fromTable2
to your local server and does the join operations locally.The drop in performance is there because it takes time to move the entire contents of
Table1
andTable2
from the remote server to the local server.Move the content of
TB_BRANCH
(25 rows) to the remote server to avoid doing a join between tables on different servers.One way of moving the rows from
TB_BRANCH
to the remote server is to execute the query on the remote server usingsp_executesql
with the values as a parameter in a XML structure. Unpack the XML to a table variable and use the table variable in your main query.I have guessed the data type of
BRANCH_ID
to bevarchar(10)
you need to modify that in two places in the script if it is something else.The XML parameter has to be a
varchar(max)
instead of asXML
since theXML
datatype is not supported with remote queries. Table Valued Parameters is not supported either so that is not an option here.The query plan of this query is not very interesting. It will just be a Remote Scan. If you want to know what the plan looks like on the remote side you have to capture the plan there.