Наслідки для продуктивності використання OPENQUERY в огляді

Будь ласка, дивіться це запитання на сайті stackoverflow:

Я використовую драйвер EasySoft ODBC, щоб зв’язати екземпляр SQL Server 2008 R2 Express з Interbase, і у мене виникли труднощі з отриманням метаданих з віддаленого сервера. З огляду на мережу в основних домаганнях всі згадуються про використання OPENQUERY замість синтаксису сервера з чотирма частинами.

EG Мій поточний (проблемний) підхід - це ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

SELECT *
FROM [LBLIVE]...[PRDETS] WITH (NOLOCK)

Але в деяких таблицях я отримую помилку під час виклику представлення ...

Посилання 7353, рівень 16, стан 1, рядок 1 Постачальник OLE DB "MSDASQL" для пов'язаного сервера "LBLIVE" надає непослідовні метадані. Під час виконання було надано додатковий стовпчик, який не був знайдений під час компіляції.

Також деякі погляди я навіть не можу створити, оскільки я отримую наступне ...

Msg 7315, Рівень 16, стан 1, рядок 1 Постачальник OLE DB "MSDASQL" для пов'язаного сервера "LBLIVE" містить кілька таблиць, які відповідають імені "" SYSDBA "." AUDIT_LBABKP "".

Хоча є лише одна із згаданих таблиць.

Альтернативний підхід до пошуку в мережі, схоже, більше схожий на ...

SELECT *
FROM OPENQUERY(<linked sevrer>, 'SELECT <column list> FROM MyTable')

Отже, моє запитання полягає в тому, що якщо я буду використовувати OPENQUERY в моєму визначенні, чи зможе SQL Server оптимізувати отриманий SQL, що надсилається на Interbase? Або дійсно немає великої різниці між двома підходами?

Це перехрестя над темою, і дуже сподобався б POV POV.

Підсумок

Нехай пов'язаний сервер робить якнайбільше.
Це неможливо для SQL Server , щоб оптимізувати запит на пов'язаному сервері, навіть інший SQL Server

Довго

Ключовим фактором є те, куди працює запит.

У цьому випадку це тривіальний ВИБІР, тому всі рядки з таблиці будуть відправлені вниз по проводу. Це не має значення.

Якщо ви додасте ПРИЄДНАЙТЕСЬ та ЧОГО, то це може мати значення. Ви хочете, щоб SQL Server дозволив зв'язаному серверу зробити якомога більше фільтрування, щоб зменшити розмір даних, що надходять по мережі.

Наприклад, другий випадок тут повинен бути ефективнішим.

SELECT *
FROM OPENQUERY(<linked server>, 
            'SELECT <column list> FROM MyTable') T1
     JOIN
     SomeLocalTable T2 ON ...
WHERE T1.foo = 'bar'

SELECT *
FROM OPENQUERY(<linked server>, 
           'SELECT <column list> FROM MyTable WHERE foo = ''bar''')
     JOIN
     SomeLocalTable T2 ON ...

Обмеженням OPENQUERY є те, що ви не можете параметризувати: тому вам потрібен динамічний SQL, щоб додати пропозиції WHERE тощо.

На продуктивність пов'язаних серверів може вплинути вплив sp_serveroption. Налаштування collation compatibleговорить все це

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

Тобто намагайтеся не дозволяти SQL Server обробляти дані локально.

Примітка. У моєму foo = 'bar'другому прикладі вище, фільтр надсилається на пов'язаний сервер, оскільки він є лише постійною послідовністю для SQL Server. Реальний пункт WHERE у першому прикладі може або не надсилається віддалено.

Нарешті, я також виявив, що розміщувати дані у тимчасовій таблиці та приєднувати їх до локальних таблиць часто краще, ніж приєднуватись безпосередньо до ОТВІТУ.