Вот есть 2 идентичных запроса:

1

UPDATE dbo.[Transfer]
SET SpendingTransactionId = (
   SELECT TOP 1 s.[Index] / 100000
   FROM dbo.Spending s
      JOIN dbo.[Transaction] tn
         ON tn.[Index] = [Transfer].[Index] / 100000
            AND tn.[Hash] = s.SourceTransactionHash)

2

UPDATE dbo.[Transfer]
SET SpendingTransactionId = s.[Index] / 100000
FROM dbo.Spending s
   JOIN dbo.[Transaction] tn
      ON tn.[Hash] = s.SourceTransactionHash
WHERE  tn.[Index] = [Transfer].[Index] / 100000

Для устанавливаемого поля (SpendingTransactionId) индекс отключен (Disabled). Для всех остальных полей, которые участвуют в выборке, есть индексы (одно поле 1 индекс).

Как понять какой запрос выполнится быстрее? Estimated execution plan в каждом из случаев показывает 100%. Куча квадратиков, а как оценить какой запрос выполнится быстрее -- Нафиг он вообще нужен этот Estimated execution plan? Как он мне может помочь в оценке?

Может есть какая статья Quik Start или кто хочет за деняжку помочь?

Данных многовато, запустил первый запрос и ждал 2 часа. Решил прибить и запустил сейчас второй.

Update (планы)

	Скрытый текст
	1 2

Можно в профайлере посмотреть реальное время выполнения, это безотносительно к планам вообще.

Здравствуйте, Temnikov, Вы писали:

T>Можно в профайлере посмотреть реальное время выполнения, это безотносительно к планам вообще.

Просто данных много, ждал 2 часа и это мне надоело.

Здравствуйте, Shmj, Вы писали:

S>Вот есть 2 идентичных запроса:

S>....

S>Для устанавливаемого поля (SpendingTransactionId) индекс отключен (Disabled). Для всех остальных полей, которые участвуют в выборке, есть индексы (одно поле 1 индекс).

S>Как понять какой запрос выполнится быстрее? Estimated execution plan в каждом из случаев показывает 100%. Куча квадратиков, а как оценить какой запрос выполнится быстрее -- Нафиг он вообще нужен этот Estimated execution plan? Как он мне может помочь в оценке?

S>Может есть какая статья Quik Start или кто хочет за деняжку помочь?

S>Данных многовато, запустил первый запрос и ждал 2 часа. Решил прибить и запустил сейчас второй.

План не является абсолютным мерилой "быстроты" запроса. При сравнении планов ориентируются на его стоимость (Estimated Subtree Cost). Однако план с лучшей стоимостью может проигрывать по времени выполнения, плану с худшей стоимостью. Вообще плана существует два — предполагаемый (estimated) и актуальный (actual). В большинстве случаев они могут совпадать, но бывают ситуации когда отличаются. При сравнении производительности запросов ориентируются так же на операции ввода/вывода (set statistics io on) и статистику по времени (set statistics time on). Навскидку могу порекомендовать автора Grant Fritchey, который написал статьи и книгу о планах запроса:
Книга (бесплатно) — SQL Server Execution Plans, 2nd Edition
Статья — Execution Plan Basics

Что касается вашей ситуации, то предполагаю, что при обновлении данных неэффективно используется индекс по полю [Transfer].[Index] за счет деления на 1000, а может быть вообще не используется. Опять же непонятно какое у вас количество данных и их распределение. Два часа ждать не обязательно, можно попробовать получить предполагаемый план и попытаться оценить стратегию получения данных. А вообще публикуйте план здесь, может кто-то и откликнется.

Здравствуйте, Shmj, Вы писали:

S>Вот есть 2 идентичных запроса:

Я бы для начала построил индекс по [Transfer].[Index] / 100000 и посмотрел планы. Ну и не помешало бы посмотреть, что предложит Tuning Advisor. Иногда он дает весьма дельные подсказки.

В общем, гадать бессмысленно, не видя планов исполнения запросов.

Здравствуйте, Olaf, Вы писали:

O>А вообще публикуйте план здесь, может кто-то и откликнется.

Добавил планы.

Здравствуйте, Shmj, Вы писали:

S>Как понять какой запрос выполнится быстрее? Estimated execution plan в каждом из случаев показывает 100%. Куча квадратиков, а как оценить какой запрос выполнится быстрее -- Нафиг он вообще нужен этот Estimated execution plan? Как он мне может помочь в оценке?

Пробую сам ответить после сна.

Видимо второй выполнится быстрее раза в 4, т.к. общая операция UPDATE (второй квадратик), в первом случае занимает 5%, во втором 18% от стоимости всего запроса. Т.к. эта операция одинаковая, то относительно нее можно сравнивать.

S>Может есть какая статья Quik Start или кто хочет за деняжку помочь?
live query statistics в твоем случае будет лучше всего.
смотреть тут начиная с тайминга 2:42
https://www.youtube.com/watch?v=Qa0dRJOhcEM&feature=youtu.be&t=2m42s

Здравствуйте, Shmj, Вы писали:

S>Вот есть 2 идентичных запроса:

Сомневаюсь, что они идентичные.

Скажем так, оба запроса могут давать неопределённые результаты.

Здравствуйте, Shmj, Вы писали:

S>Вот есть 2 идентичных запроса:

S>1
S>

S>UPDATE dbo.[Transfer]
S>SET SpendingTransactionId = (
S>   SELECT TOP 1 s.[Index] / 100000
S>   FROM dbo.Spending s
S>      JOIN dbo.[Transaction] tn
S>         ON tn.[Index] = [Transfer].[Index] / 100000
S>            AND tn.[Hash] = s.SourceTransactionHash)
S>

Ни WHERE в UPDATE, ни условия кореляции поздапроса с главным запросом...

Ты точно ничего не забыл ?

Здравствуйте, MasterZiv, Вы писали:

MZ>Ни WHERE в UPDATE, ни условия кореляции поздапроса с главным запросом...

Корреляция вроде есть:

ON tn.[Index] = [Transfer].[Index] / 100000

И вполне можно представить схему где запрос корректен, но TOP без ORDER всё равно смотрится странно.