SQL Sub-Query performance issue

Question

I'm having performance issues with my SQL sub query.

As a hard-coded query, it takes about 1 second to run:

SELECT   ColumnA
        ,ColumnB
        ,ColumnC
FROM    [LinkedServer].[Database].[Schema].[View]
WHERE   ColumnA IN 
    (
        'ABC',
        'DEF',
        'HIJ',
        'KLM'
    )

However, the following code takes over a minute to run:

SELECT   ColumnA
        ,ColumnB
        ,ColumnC
FROM    [LinkedServer].[Database].[Schema].[View]
WHERE   ColumnA IN 
    (
        SELECT ColumnA FROM #TempTable
    )

The temp table contains the same 4 rows as the hard-coded example. The view on the linked server contains approx. 700,000 rows (and, unfortunately, is outside of my control). The ColumnA data types are the same and both tables are indexed.

Any ideas on how to improve the performance of this query?

Many thanks.

Answer 1

Try a JOIN instead:

SELECT   V.ColumnA
        ,V.ColumnB
        ,V.ColumnC
FROM    [LinkedServer].[Database].[Schema].[View] V
INNER JOIN #TempTable T ON V.ColumnA = T.ColumnA

Answer 2

Its probably related to how the query plan is created. In one case SQL server knows what values it will be using in the comparison, in the second it is estimating. Run each query in a seperate Management Studio window after clicking the "Include Actual Excecution Plan." You will probably see different plans. The first thing I would check is to hover over the arrows linking the actions (start with the fat ones) and compare the Estimated number of Rows to the Actual number of rows. A large disparity (factor of 10?) in these values can cause SQL server to make the wrong decision (table scan vs index etc.) If you see this you might consider a hint to get SQL to change its plan - if you need to use the slow query! The big problem with hints is that as the data volumes change the hint can easily become a hindrance rather that a benefit, so they are considered to be a last resort.

Answer 3

The linked server supplier has provided me with a different source. Instead of connecting to a view (which itself was spread over multiple servers), I now connect to a single table. This, combined with Brian's INNER REMOTE JOIN suggestion returns the full dataset almost immediately.

Whilst it's a little frustrating that I couldn't follow the enhanced privileges/linked server options, at least this query is working well.

Many thanks for everyone's help!