Использует ли MERGE tempdb?

Рассмотрим следующий запрос:

MERGE [Parameter] with (rowlock) AS target
    USING (SELECT @AreaId, @ParameterTypeId, @Value)
            AS source (AreaId, ParameterTypeId, Value)
    ON (target.AreaId = source.AreaId AND 
        target.ParameterTypeId = source.ParameterTypeId)
    WHEN MATCHED THEN 
        UPDATE SET target.Value = source.Value, @UpdatedId = target.Id
    WHEN NOT MATCHED THEN
        INSERT ([AreaId], [ParameterTypeId], [Value])
        VALUES (source.AreaId, source.ParameterTypeId, source.Value);

Статистика ввода-вывода дает следующий результат:

  

Таблица 'ParameterType'. Количество отсчетов 0, логическое чтение 2, физическое чтение 0, чтение вперед 0, логическое считывание логических чисел 0, физическое чтение lob 0, чтение с чтением lob 0.   
Таблица «Площадь». Количество отсчетов 0, логическое чтение 2, физическое чтение 0, чтение вперед 0, логическое считывание логических чисел 0, физическое чтение lob 0, чтение с чтением lob 0.   
Таблица «Параметр». Число сканирования 1, логическое чтение 4, физическое чтение 0, чтение вперед 0, логическое чтение лоб 0, физическое чтение lob 0, чтение с чтением lob 0.   
Таблица «Рабочий стол». Число сканирования 1, логическое чтение 0, физическое чтение 0, чтение вперед 0, логическое чтение lob 0, физическое чтение lob 0, чтение с чтением lob 0.

На вкладке сообщений отображается рабочий стол, который заставляет меня думать, что tempdb используется MERGE.

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

Есть ли MERGE всегда использовать tempdb?

Есть ли что-нибудь в BOL, объясняющее это поведение?

Использовал бы INSERT & UPDATE быстрее в этой ситуации?

Left

введите описание изображения здесь>> </p>

<p> <strong> Right </STRONG> </p>

<p> <img src =

12 голосов | спросил Craig Efrein 18 J000000Thursday13 2013, 13:12:13

2 ответа


8

(Расширение моего комментария к вопросу.)

Без уникального ограничения на комбинацию AreaId и ParameterTypeId, данный код поврежден, потому что @UpdatedId = target.Id будет записывать только одну строку Id

Если вы этого не скажете, SQL Server не может неявно узнать возможные состояния данных. Либо ограничение должно быть принудительно, либо если несколько строк valid , код нужно будет изменить, чтобы использовать другой механизм для вывода кода Id.

Из-за того, что оператор сканирования встретит несколько совпадающих строк, запрос должен сгенерировать все совпадения для защиты Хэллоуина. Как указано в комментариях, ограничение равно , поэтому добавление его не только изменяет план от сканирования до поиска, но также устраняет необходимость в буферизации таблицы, поскольку SQL Server будет знать там будет либо 0, либо 1 строка, возвращаемая оператором поиска.

ответил Jon Seigel 18 J000000Thursday13 2013, 19:51:26
6

Если обновление может изменить положение строки в индексе, отсканированном при обновлении, SQL Server необходимо защитить от проблемы Хэллоуина . Для этого SQL Server обычно вставляет требуемый столбец в план выполнения сразу после сканирования индекса. Этот оператор в основном создает копию соответствующих строк и использует для этого tempdb.

Часть обновления инструкции MERGE должна следовать тем же правилам, а также использовать столбчатую катушку в большинстве случаев, когда требуется защита Хэллоуина.

Пока я не могу сказать, так ли это в вашем запросе, поскольку я не знаю определения индекса, это, скорее всего, то, что здесь происходит.

ответил Sebastian Meine 18 J000000Thursday13 2013, 16:28:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132