Продуктивність пов'язаного сервера SQL Server: Чому віддалені запити такі дорогі?

У мене є два сервери баз даних, підключені через пов'язані сервери. Обидва є базами даних SQL Server 2008R2, і з'єднання зв'язаним сервером здійснюється за допомогою звичайного посилання "SQL Server", використовуючи поточний контекст безпеки входу. З’єднані сервери обидва в одному центрі обробки даних, тому з'єднання не повинно бути проблемою.

Я використовую наступний запит, щоб перевірити, які значення стовпця identifierдоступні віддалено, але не локально.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT DISTINCT
    identifier 
FROM LocalDb.schema.[TableName] 

В обох таблицях є некластеризовані індекси стовпця identifier. Місцеве значення складає близько 2,6М рядків, віддалено лише 54. Проте, дивлячись на план запитів, 70% часу на виконання приділяється "виконанню віддаленого запиту". Також при вивченні повного плану запитів 1замість 2695380(приблизно, кількість передбачуваних рядків при виборі лише запиту, що надходить після EXCEPT), замість ( приблизно, кількість оцінюваних місцевих рядків ). Виконання цього запиту дійсно займає багато часу.

Мене змушує замислитися: чому це? Невже оцінка "просто" відсторонена, чи віддалені запити на пов'язаних серверах насправді такі дорогі?

План, який ви маєте на даний момент, виглядає як найоптимальніший для мене план.

Я не згоден з твердженням в інших відповідях про те, що він надсилає рядки 2.6M на віддалений сервер.

План виглядає так, ніби для кожного з 54 рядків, повернених із віддаленого запиту, він виконує індекс, пошукайте у вашу локальну таблицю, щоб визначити, чи відповідає він чи ні. Це майже оптимальний план.

Заміна хеш-об'єднання або об'єднання об'єднань буде контрпродуктивною, враховуючи розмір таблиці, а додавання проміжної #tempтаблиці просто додає додатковий крок, який, здається, не дає вам жодної переваги.

Підключення до віддаленого ресурсу дорого. Період.

Однією з найдорожчих операцій у будь-якому середовищі програмування є мережевий IO (хоча дисковий IO, як правило, карликовим).

Це поширюється на віддалені пов'язані сервери. Сервер, що викликає віддалений зв'язаний сервер, спочатку повинен встановити з'єднання, після чого потрібно виконати запит на віддаленому сервері, повернути результати та закрити з'єднання. Це все вимагає часу через мережу.

Ви також повинні структурувати свій запит таким чином, щоб ви переносили мінімальну кількість даних по лінії. Не чекайте, що БД оптимізується для вас.

Якби я писав цей запит, я вибрав би віддалені дані в змінну таблиці (або в таблицю темпів), а потім використав би це разом із локальною таблицею. Це гарантує, що будуть передані лише ті дані, які потрібно передавати.

Запит, який ви виконуєте, може легко надсилати 2,6М рядків на віддалений сервер, щоб обробити EXCEPTпункт.

Я не є експертом, але якщо ви використовуєте Union, крім або Intersect, вам не доведеться використовувати "Distinct". Залежно від значень LocalDb.schema. [TableName], ефективність запиту може бути покращена.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT 
    identifier 
FROM LocalDb.schema.[TableName]

Один правильний, проблема продуктивності викликається надсиланням рядків 2,6М на віддалений сервер.

Щоб вирішити цю проблему, ви можете змусити віддалені дані (54 рядки), які надсилаються вам, використовуючи темп або таблицю пам'яті.

Використання тимчасової таблиці

SELECT  identifier 
INTO    #TableName
FROM    LinkedServer.RemoteDb.schema.[TableName]

SELECT  identifier
FROM    #TableName
EXCEPT
SELECT  DISTINCT identifier 
FROM    LocalDb.schema.[TableName] 

DROP    #TableName

Думаю, вам краще реплікувати віддалену таблицю на сервер, від якого ви запитуєте, а потім запустити всі свої SQL локально.