2010-11-18 3 views
7

Я получил этот запросМедленный запрос при подключении к связанному серверу

UPDATE linkeddb...table SET field1 = 'Y' WHERE column1 = '1234'

Это займет 23 секунд, чтобы выбрать и обновить одну строку

Но если я использую OPENQUERY (который я не хочу), то это займет всего полсекунды.

Причина, по которой я не хочу использовать openquery, заключается в том, что я могу надежно добавить параметры в свой запрос и быть в безопасности от SQL-инъекций.

Кто-нибудь знает, почему он работает так медленно?

+0

Любые подсказки из плана выполнения запроса?Или вы можете настроить SQL Profiler для просмотра базы данных и посмотреть, что openquery делает по-другому. – Rup

ответ

8

Вот мысль как альтернатива. Создайте хранимую процедуру на удаленном сервере для выполнения обновления, а затем вызовите эту процедуру из своего локального экземпляра.

/* On remote server */ 
create procedure UpdateTable 
    @field1 char(1), 
    @column1 varchar(50) 
as 
    update table 
     set field1 = @field1 
     where column1 = @column1 
go 

/* On local server */ 
exec linkeddb...UpdateTable @field1 = 'Y', @column1 = '1234' 
+0

@Joe - это хранимая процедура, в основном просто функция/метод для базы данных? – orokusaki

+0

@orokusaki: Да, вы можете так думать. –

+0

@Joe Это будет работать только немного быстрее из-за удаления сеанса синтаксического разбора и компиляции. @orokusaki Он по-прежнему лучше, чем ваш метод, поскольку он позволяет базе данных защищать себя от SQL-инъекции. Вы также можете установить разрешения, чтобы пользователь не мог напрямую обновить таблицу и может выполнять только через SP. – stevenrcfox

2

Является ли первичный ключ столбца1? Возможно нет. Попробуйте выбрать записи для обновления с использованием первичного ключа (где PK_field = xxx), в противном случае (иногда?) Все записи будут прочитаны, чтобы найти PK для записей для обновления.

+0

Я уверен, что column1 является первичным ключом, но, глядя на план выполнения SQL Query Analyzer, он показывает, что удаленное сканирование занимает самое большое время, поэтому кажется, что он просматривает все 40 000 записей. –

+2

Хмм, если ваш PK является (n) varchar, тогда у вас может быть проблема с сортировкой (я имею в виду, что SQL не использует такой индекс, потому что он не знает сортировки или так). Однако у меня нет опыта работы с нецелочисленными полями PK. – Arvo

+0

@Jamie, I вторая теория сопоставления Arvo является потенциальной проблемой – stevenrcfox

1

Является ли column1 полем varchar? Именно поэтому вы окружаете значение 1234 с помощью кавычек? Или это просто опечатка в вашем вопросе?

+0

Если я запустил запрос в Query Analyzer без кавычек, я получаю сообщение об ошибке, и я считаю, что column1 является полем varchar. –

4

Если вы ищете почему, вот возможность из Linchi Shea's Blog:

Чтобы создать лучшие планы запросов, когда вы используете таблицу на связанном сервере, процессор запросов должен иметь статистику распространения данных с связанного сервера . Пользователи, которые имеют ограниченные разрешения на каких-либо столбцах таблицы не имеют достаточных разрешения, чтобы получить все полезные статистик, и могут получить Aless эффективного плана запроса и опыт плохой производительность. Если связанный serveris экземпляр SQL Server, чтобы получить все имеющиеся статистические данные, то пользователь должен владеть таблицей или быть членом роли сервера сисадмина фиксирована, db_ownerfixed роль базы данных или фиксированной роли базы данных db_ddladmin на сервере ссылок .

(Из-за сообщения Линчи это разъяснение было добавлено в последнюю документацию BooksOnline SQL).

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

Вот related SO question о производительности связанного сервера. Их вывод: использование OpenQuery для лучшей производительности.

Обновление: additional excellent posts о производительности связанного сервера от блога Linchi.

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