Эффект синонимов над связанным сервером в SQL Server

В локальном сервере (SQL Server 2008 R2) у меня есть синоним syn_view1, указывающий на связанный сервер remoteserver.remotedb.dbo.view1

Этот SLOW-запрос занимает 20 секунд для запуска.

select e.column1, e.column2
from syn_view1 e
where e.column3 = 'xxx'
  and e.column4 = 'yyy'
order by e.column1

Этот запрос FAST занимает 1 секунду для запуска.

select e.column1, e.column2
from remoteserver.remotedb.dbo.view1 e
where e.column3 = 'xxx'
  and e.column4 = 'yyy'
order by e.column1

Единственное различие в двух запросах - это действительно синоним. Очевидно, синоним влияет на производительность запроса.

План выполнения SLOW-запроса:

Plan                Cost %  Subtree cost
4 SELECT
I/O cost: 0.000000  CPU cost: 0.000000  Executes: 0  
Cost: 0.000000                  0.00    3.3521
    3 Filter
    I/O cost: 0.000000  CPU cost: 0.008800  Executes: 1  
    Cost: 0.008800              0.26    3.3521
        2 Compute Scalar
        I/O cost: 0.000000  CPU cost: 3.343333  Executes: 1  
        Cost: 0.000000          0.00    3.3433
            1 Remote Query
            I/O cost: 0.000000  CPU cost: 3.343333  Executes: 1  
            Cost: 3.343333      99.74   3.3433

И для запроса FAST:

Plan            Cost %  Subtree cost
3 SELECT
I/O cost: 0.000000  CPU cost: 0.000000  Executes: 0  
Cost: 0.000000              0.00    0.1974
    2 Compute Scalar
    I/O cost: 0.000000  CPU cost: 0.197447  Executes: 1  
    Cost: 0.000000          0.00    0.1974
        1 Remote Query
        I/O cost: 0.000000  CPU cost: 0.197447  Executes: 1  
        Cost: 0.197447      100.00  0.1974

Я понимаю, что в SLOW-запросе сервер извлекает все данные с удаленного сервера, затем применяет фильтр (хотя и без индекса), тогда как в запросе FAST сервер извлекает отфильтрованные данные с удаленного сервера, используя, таким образом, удаленные индексы.

Есть ли способ использовать синоним, будучи быстрым? Может быть, установка связанного сервера? сервер локальной базы данных?

Спасибо за помощь!

Ответ 1

Я бы сбросил данные без на в временную таблицу на локальном сервере. Затем я выберет из таблицы temp порядок. Заказ почти всегда является убийцей.

Ответ 2

В принятом ответе на этот пост на dba.stacexchange.com отмечается, что производительность запросов может возникать в запросах по связанным серверам из-за ограниченных прав доступа на связанном сервере, ограничивая видимость статистики таблицы локальному серверу. Это может повлиять на план запроса и, следовательно, на производительность.

Выдержки:

И вот почему я получил разные результаты. При работе в качестве sysadmin я получила полную статистику распределения, которая указала, что нет строки с идентификатором заказa > 20000, а оценка - одна строка. (Напомним, что оптимизатор никогда не принимает нулевые строки из статистики.) Но когда как обычный пользователь, DBCC SHOW_STATISTICS завершился неудачей с ошибка разрешения. Эта ошибка не распространялась, но вместо этого оптимизатор согласился с тем, что не было статистики и использовалось значение по умолчанию предположения. Поскольку он получил информацию о мощности, он узнал, что удаленная таблица имеет 830 строк, откуда оценивается 249 строк.