0

Это моя проблема. Я определил связанный сервер, назовем его LINKSERV, который имеет базу данных под названием LINKDB. На моем сервере (MYSERV) У меня есть база данных MYDB.Одиночный SELECT со связанным сервером делает несколько SELECT по ID

Я хочу выполнить запрос ниже.

SELECT * 
FROM LINKSERV.LINKDB.LINKSCHEMA.LINKTABLE 
    INNER JOIN MYSERV.MYDB.MYSCHEMA.MYTABLE ON MYKEYFIELD = LINKKEYFIELD 

Проблема заключается в том, что, если я взгляну на профилировщик, я вижу, что в LINKSERV сервера много отборных сделано. Они выглядит аналогично:

SELECT * 
FROM LINKTABLE WHERE LINKKEYFIELD = @1 

Где @1 это параметр, который изменяется для каждого ВЫБРАТЬ. Это, конечно, нежелательно, потому что оно, кажется, не работает. Я мог ошибаться, но я полагаю, что проблема связана с использованием разных серверов в JOIN. На самом деле, если я избегу этого, проблема исчезнет.

Я прав? Есть ли решение? Заранее спасибо.

+0

Это называется параметризованным запросом, и он должен работать достаточно хорошо. Пожалуйста, выполните поиск по этому термину. Может быть, вы должны добавить индекс в LINKTABLE.LINKKEYFIELD – Hogan

+0

Это не связано с параметризованными запросами. Запросы по связанным серверам должны вести себя по-разному. Кстати, о какой версии SQL Server мы говорим? –

+0

** MYSERV ** - SQL2008R2, а ** LINKSERV ** - SQL2008. – ufo

ответ

1

То, что вы видите, может быть оптимальным решением, поскольку у вас нет операторов фильтра, которые можно было бы использовать для ограничения количества строк, возвращаемых с удаленного сервера.

Когда вы выполняете запрос, который извлекает данные с двух или более серверов, оптимизатор запросов должен решить, что делать: вытащить большое количество данных на запрашивающий сервер и выполнить соединения там или как-то отправить части запроса на связанный сервер для оценки? В зависимости от фильтров и доступности или качества статистики на обоих серверах оптимизатор может выбирать разные операции для объединения (слияние или вложенный цикл).

В вашем случае он решил, что локальная таблица имеет меньшее количество строк, чем цель, и запрашивает целевую строку, соответствующую каждой из локальных строк.

Такое поведение и способы улучшения производительности описаны в Linked Server behavior when used on JOIN clauses

Очевидные оптимизации обновить статистику и добавить WHERE заявления, которое фильтрует строки, возвращаемые из удаленной таблицы. Другая оптимизация заключается в том, чтобы возвращать только нужные столбцы с удаленного сервера, вместо того, чтобы выбирать *

+0

Спасибо за ответ. Конечно, предлагаемые вами оптимизации уже реализованы в реальном сценарии. Существуют также индексы для полей, используемых в соединении. Производительность по-прежнему не очень хороша для нас. Мы должны ввести самую мощную логику импорта. Еще один вопрос, вы думаете, что 'OPENROWSET' может быть хорошей альтернативой для связанных серверов, или это последнее лучше в любом случае? Спасибо. – ufo

Смежные вопросы