Оптимизированные для памяти таблицы:
Насколько я понимаю, статистика по таблицам, оптимизированным для памяти (MO), создается во время создания таблицы и является пустой, и она никогда не обновляется. Чтобы обновить статистику таблицы MO по индексам, мне нужно вручную принудительно обновить статистику, когда в таблице есть данные.
Большинство моих таблиц MO являются заменой таблиц #temp в хранимых процедурах и определены с долговечностью только для схемы.
Каждому вызову хранимой процедуры присваивается «идентификатор сеанса», и у меня есть задание, которое периодически очищает таблицы MO на основе старых «идентификаторов сеансов».
С учетом вышесказанного, время, когда таблицы МО содержат наибольшее количество данных, находится непосредственно перед очисткой. Поэтому имеет смысл обновить статистику таблицы в рамках процедуры очистки и непосредственно перед инструкциями удаления.
Собственно-скомпилированные хранимые процедуры:
Так же, как таблицы MO, план запроса для хранимых процедур, скомпилированных в естественном виде (NC), создается во время создания процедуры и обновляется только после перезапуска SQL Server. Во время создания процедуры или перезапуска SQL Server таблицы MO пусты, так как они определены с долговечностью только для схемы. Единственный способ воссоздать план запроса - удалить хранимую процедуру ЧПУ и воссоздать ее, как только данные появятся в таблицах МО. Это означает, что процедура должна выполняться хотя бы один раз без соответствующего плана запроса. Это недопустимо - ни запускать процедуру один раз без соответствующего плана запроса, ни заново создавать процедуры ЧПУ во время нормальной работы.
Другим вариантом является использование подсказок индекса и форсированный порядок для каждого запроса в хранимой процедуре ЧПУ. Это заставляет разработчика создавать план запроса и игнорировать SQL Server. Если это так, мы можем также работать на C ++ или C # и не беспокоиться о процедурах NC.
Есть ли предложения о том, как лучше использовать таблицы MO и хранимые процедуры NC? Я использую SQL Server 2014, но я считаю, что это справедливо для более поздних версий SQL Server.