Чи MERGE використовує tempdb?

12

Розглянемо наступний запит:

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);

Статистика вводу-виводу дає такий вихід:

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

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

Я не бачу нічого в Плані виконання, що вказувало б на необхідність tempdb

Чи MERGEзавжди використовується tempdb?

Чи є щось у BOL, що пояснює таку поведінку?

Чи буде використання INSERT& UPDATEшвидше в цій ситуації?

Зліва

введіть тут опис зображення

Правильно

введіть тут опис зображення

Ось структура таблиці

введіть тут опис зображення

sql-server t-sql

— Крейг Ефрейн
джерело

Котушка в плані - це робочий стіл tempdb. Здається, не дивно, що саме там є для одного ряду. Я думаю, що це може бути для захисту на Хеллоуїн.

— Мартін Сміт

Я бачу це зараз. Зберігає дані з вхідних даних у тимчасову таблицю для оптимізації перемотування назад.

— Крейг Ефрейн

8

^{(Розширюю мій коментар до питання.)}

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

Якщо ви не скажете це так, SQL Server не може неявно знати можливі стани даних. Або обмеження слід примусово застосовувати, або якщо кілька рядків є дійсними , код потрібно буде змінити, щоб використовувати інший механізм для виведення Idзначень.

З-за можливості, що оператор сканування зіткнеться з декількома відповідними рядками, запит повинен охоче спустіть всі збіги для захисту Хеллоуїна. Як зазначено в коментарях, обмеження є дійсним, тому додавання його не лише змінить план від сканування до пошуку, але й усуне необхідність в котушці таблиць, оскільки SQL Server буде знати, що це буде або 0, або 1 рядок повернуто від оператора пошуку.

— Джон Сейгель
джерело

6

Якщо оновлення може змінити позицію рядка в індексі, відсканованому оновленням, SQL Server потрібно захистити від проблеми Хеллоуїна . Для цього SQL Server зазвичай вставляє нетерплячий котушок таблиці в план виконання відразу після сканування індексу. Цей оператор в основному створює копію відповідних рядків і використовує для цього tempdb.

Частина оновлення оператора MERGE повинна відповідати тим же правилам, а також використовує котушку таблиці в більшості випадків, коли потрібен захист на Хеллоуїн.

Хоча я не можу сказати, чи це так у вашому запиті, оскільки я не знаю визначення (-ів) індексу, це, швидше за все, що відбувається тут.

— Себастьян Мейн
джерело