Использование таблиц OLTP в памяти вместо временных таблиц

Question

SQL Server 2014 представил то, что кажется отличной функцией: In-Memory OLTP (оптимизация в памяти). Это напоминает мне о MySQL's MEMORY Storage Engine, который я попробовал несколько лет назад и получил большую производительность.

Я знаю, что об этом уже спрашивали, но меня интересует более целенаправленный сценарий:

Несколько SSRS В отчетах используются большие хранимые процедуры, которые по причинам производительности (очень уродливые и медленные планы выполнения для запросов с большим количеством объединений, группировок и т. д.) разделяют логику с помощью временных таблиц для хранения частичных результатов.

Поскольку временные таблицы записываются на диск, я ожидаю, что это повлияет на производительность при работе с большим количеством данных (десятки или даже сотни тысяч строк).

Использует ли In-Memory OLTP tables имеет смысл в этом сценарии? Я думаю о следующих плюсах и минусах.

Плюсы:

• должно быть значительно быстрее, так как все данные хранятся в памяти

Минусы:

• требует явного разделения сеансов (таблица должна включать в себя какой-то идентификатор сеанса, чтобы не смешивать данные из различных SPIDs)
• требует явной очистки данных во избежание нехватки памяти (в отличие от временных таблиц, автоматически удаляемых после выхода из области объявления)
• Необходимо обратить внимание на объем данных, хранящихся в таблице

Answer 1

Вы получили это право.

Обратите внимание, что временные таблицы, как и любая другая таблица, пишутся лениво (даже более лениво, чем обычно). Запись на диск обычно не находится на критическом пути, потому что это происходит асинхронно. За исключением очень больших временных таблиц, которые исчерпывают способность SQL Server сохранять грязные буферы в памяти.

Кроме того, если временная таблица освобождается быстро, вообще не будет никаких записей страницы.

Таким образом, "профи", которое вы перечислили там, часто не вступает в (полный) эффект.

При этом таблицы в памяти, как правило, используют меньше ресурсов ЦП даже в режиме взаимодействия. Так что "профи" всегда хоть немного правдиво.

Вы можете рассмотреть возможность использования таблиц Hekaton только для схемы. Это не приведет к записи данных точно.