Временные таблицы и табличные переменные в SQL Server

Оба варианта хранят промежуточные строки, но статистика, компиляция, индексы и транзакции могут создавать совершенно разные планы.

Почему тема требует системного внимания

Такая проблема редко существует изолированно. Изменение, ускоряющее один запрос, может увеличить записи, журнал, блокировки, время восстановления или сложность в другом месте. Рассматривайте работу как инженерное решение с измеримой целью, известными ограничениями и ответственным владельцем.

Выбирайте структуру, которая дает оптимизатору достаточно информации при разумной стоимости промежуточной работы.

Что измерять

Измеряйте фактические строки, оценки, выбор join, spills, recompilations и повторный доступ. Deferred compilation помогает в части случаев, но не делает структуры взаимозаменяемыми.

Процесс диагностики

• Точно определите симптом, затронутую нагрузку, время начала, частоту и влияние на пользователей.
• Соберите данные в нормальном и деградировавшем периодах для одной и той же бизнес-операции.
• Отделите корреляцию от причины, проверив планы, ожидания, ресурсы, блокировки, конфигурацию и изменения.
• Тестируйте репрезентативные группы баз, запросов или параметров, а не только самый простой пример.
• Сохраните текущую настройку, план, определение объекта и счетчики до любого изменения.
• Задайте числовой ожидаемый результат: latency, CPU, logical reads, throughput, queue или recovery time.

Как выбрать вмешательство

Предпочитайте самое узкое изменение, устраняющее доказанную причину. Настройки сервера влияют на многие нагрузки, а запрос, индекс, статистика или расписание часто позволяют действовать точнее. Учитывайте лицензию, версию SQL Server, доступность, окна обслуживания и возможность мониторинга.

Практический подход

Используйте временные таблицы для больших или изменчивых наборов, добавляйте только полезные индексы, выбирайте переменные для малых простых наборов и тестируйте на production-масштабе.

Безопасная последовательность внедрения

• Воспроизведите поведение в безопасной среде на данных производственного масштаба.
• Меняйте по одной существенной переменной и сохраняйте исходное определение для отката.
• Измеряйте длительность, CPU, чтения, записи, ожидания, память, журнал и последующие эффекты.
• Проверяйте обычные, пиковые и крайние входы, а также restart или failover при необходимости.
• Внедряйте в подходящее окно при доступности оператора, владельца приложения и ответственного за откат.
• Оцените результат сразу и повторно во время следующего репрезентативного пика.

Пример для SQL Server

Следующий пример является отправной точкой для анализа или контролируемого внедрения. Адаптируйте имена, пороги, хранение и разрешения до production. Сохраняйте вывод вместе с временной шкалой инцидента и не считайте один снимок полной диагностикой.

CREATE TABLE #SelectedOrders
(
    OrderId bigint NOT NULL PRIMARY KEY,
    CustomerId int NOT NULL,
    OrderDate datetime2 NOT NULL
);

INSERT #SelectedOrders (OrderId, CustomerId, OrderDate)
SELECT OrderId, CustomerId, OrderDate
FROM dbo.Orders
WHERE OrderDate >= @StartDate;

-- Test estimates and downstream joins at production-scale row counts.

Чего следует избегать

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

Мониторинг после изменения

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

Откат и ответственность

Откат должен содержать точное предыдущее значение или определение, ответственного за решение и сигнал отмены. Для планов и метаданных сохраните исходный план и скрипт объекта. Для инфраструктуры заранее подтвердите доступную емкость и время обслуживания.

Эксплуатационный результат

Выбирайте структуру, которая дает оптимизатору достаточно информации при разумной стоимости промежуточной работы.

Проверка перед production

Зафиксируйте исходные показатели и определите ожидаемое улучшение. Проверьте решение на репрезентативных данных и при реальной параллельной нагрузке. Сохраните исходную настройку или план, подготовьте откат и наблюдайте следующий обычный пик нагрузки.

Вопросы перед закрытием работы

• Улучшился ли исходный симптом при той же нагрузке?
• Появились ли новые затраты на запись, хранение, блокировки, память или доступность?
• Сохранится ли результат после restart, failover, обновления статистики и роста данных?
• Обнаружит ли мониторинг регрессию раньше пользователей?
• Зафиксированы ли решение, владелец и дата пересмотра?

Чтобы применить этот подход к конкретной среде SQL Server, используйте форму ниже и укажите версию SQL Server, размер базы, профиль нагрузки и уже собранные данные.