Statistics

Область применения:SQL ServerБаза данных SQL AzureУправляемый экземпляр SQL AzureAzure Synapse AnalyticsБаза данных SQL в Microsoft Fabric

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

Компоненты и основные понятия

Statistics

Статистика для оптимизации запросов представляет собой большие двоичные объекты (BLOB-объекты) со сведениями о распределении значений в одном или нескольких столбцах таблицы или индексированного представления. Оптимизатор запросов использует эти статистические сведения для оценки кратности — числа строк в результатах запроса. Эти оценки кардинальности позволяют оптимизатору запросов создать качественный план выполнения запроса. Например, в зависимости от предикатов оптимизатор запросов может использовать оценку кратности, чтобы выбрать оператор index seek вместо оператора index scan, который потребляет больше ресурсов, если благодаря этому повысится производительность запроса.

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

Histogram

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

Note

SQL Server создает гистограммы только для одного столбца — первого столбца в наборе ключевых столбцов объекта статистики.

Чтобы создать гистограмму, оптимизатор запросов сортирует значения столбцов, вычисляет количество значений, совпадающих с каждым отдельным значением столбца, а затем осуществляет статистическую обработку значений столбцов с получением непрерывных шагов гистограммы, максимальное количество которых составляет 200. Каждый шаг гистограммы включает диапазон значений столбцов, за которым следует значение столбца, представляющее собой верхнюю границу. В этот диапазон входят все возможные значения столбца между граничными значениями, за исключением самих граничных значений. Наименьшим из отсортированных значений столбца является верхнее граничное значение первого шага гистограммы.

Более подробно SQL Server создает гистограмму из отсортированного набора значений столбцов в трех шагах:

• Инициализация гистограммы: на первом шаге обрабатывается последовательность значений, начиная с начала сортированного набора; собирается до 200 значений range_high_key, equal_rows, range_rows и distinct_range_rows (range_rows и distinct_range_rows всегда равны нулю на этом шаге). Первый шаг заканчивается либо при исчерпании всех входных данных, либо при обнаружении 200 значений.
• Сканирование с слиянием контейнеров: каждое дополнительное значение из ведущего столбца ключа статистики обрабатывается во втором шаге в отсортированном порядке. Каждое последовательное значение добавляется в последний диапазон или создается новый диапазон в конце (это возможно, так как входные значения отсортированы). Если создается новый диапазон, одна пара соседних существующих диапазонов объединяется в один диапазон. Эта пара диапазонов выбирается с целью уменьшения информационных потерь. Этот способ использует алгоритм максимальной разности для сведения к минимуму числа шагов в гистограмме и вместе с тем максимального увеличения разницы между граничными значениями. Число шагов после сворачивания диапазонов на протяжении этого шага остается равным 200.
• Консолидация гистограммы: на третьем шаге можно свернуть больше диапазонов, если это не приведет к утрате значительного объема информации. Число шагов гистограммы может быть меньше, чем количество различающихся значений, даже для столбцов, в которых число граничных точек меньше 200. Таким образом, даже если столбец имеет более 200 уникальных значений, гистограмма может иметь менее 200 шагов. Для столбца, состоящего только из уникальных значений, консолидированная гистограмма имеет не менее трех шагов.

Note

Если гистограмма построена с использованием выборки, а не полного сканирования, значения equal_rows, range_rows, distinct_range_rows и average_range_rows являются оценочными, поэтому они не обязаны быть целыми числами.

На следующей диаграмме показана гистограмма с шестью шагами. Первый шаг — это область слева от первого верхнего граничного значения.

Для каждого шага гистограммы в предыдущем примере:

• Полужирная строка представляет значение верхней границы (range_high_key) и количество случаев его возникновения (equal_rows).

• Сплошная область слева от range_high_key представляет диапазон значений столбцов и среднее количество случаев, когда каждое значение столбца происходит (average_range_rows). В первом шаге гистограммы значение average_range_rows всегда равно 0.

• Пунктирные линии представляют выборку значений, используемых для оценки общего числа уникальных значений в диапазоне (distinct_range_rows) и общего количества значений в диапазоне (range_rows). Оптимизатор запросов использует range_rows и distinct_range_rows для вычислений average_range_rows и не сохраняет образцы значений.

Вектор плотности

плотность — это сведения о количестве дубликатов в заданном столбце или сочетании столбцов и вычисляется как 1/(число отдельных значений). Оптимизатор запросов использует плотности для улучшения оценки размерности для запросов, которые возвращают данные нескольких столбцов из одной таблицы или индексированного представления. По мере повышения плотности избирательность значения повышается. Например, в таблице, представляющей автомобили, много автомобилей имеют одного производителя, но каждый автомобиль имеет уникальный идентификационный номер транспортного средства (VIN). Индекс по VIN более селективен, чем индекс по производителю, поскольку у VIN плотность ниже, чем у производителя.

Note

Частота — это информация о частоте появления каждого отдельного значения в первом ключевом столбце объекта статистики и вычисляется как row count * density. В столбцах с уникальными значениями максимальная частота равна 1.

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

Префикс столбца	Плотность, рассчитанная на основе
(CustomerId)	Строки с соответствующими значениями для CustomerId
(CustomerId, ItemId)	Строки с соответствующими значениями для CustomerId и ItemId
(CustomerId, ItemId, Price)	Строки с соответствующими значениями для CustomerId, ItemIdи Price

Отфильтрованная статистика

Отфильтрованная статистика может повысить производительность запросов, которые выполняют выборку из четко определенных подмножеств данных. Отфильтрованная статистика использует предикат фильтра для выбора подмножества данных, включенных в статистику. Грамотно отфильтрованная статистика может улучшить план выполнения запроса по сравнению со статистикой по полной таблице. Дополнительные сведения о предикате фильтра см. в разделе CREATE STATISTICS. Дополнительные сведения об условиях создания отфильтрованной статистики см. в подразделе Условия создания статистики этой статьи.

Параметры статистики

Вы можете настроить параметры, влияющие на то, когда и как система создает и обновляет статистику. Эти параметры можно задать только на уровне базы данных.

параметр AUTO_CREATE_STATISTICS

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

Когда оптимизатор запросов создает статистику в результате использования AUTO_CREATE_STATISTICS параметра, имя статистики начинается с _WA. Следующий запрос можно использовать для определения того, создал ли оптимизатор запросов статистику для столбца предиката запроса.

SELECT OBJECT_NAME(s.object_id) AS object_name,
    COL_NAME(sc.object_id, sc.column_id) AS column_name,
    s.name AS statistics_name
FROM sys.stats AS s
    INNER JOIN sys.stats_columns AS sc
        ON s.stats_id = sc.stats_id
        AND s.object_id = sc.object_id
WHERE s.name LIKE '_WA%'
ORDER BY s.name;

параметр AUTO_UPDATE_STATISTICS

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

Маркировка статистики как устаревшей на основе изменений строк происходит даже в том случае, если параметр AUTO_UPDATE_STATISTICS имеет OFFзначение. Если этот AUTO_UPDATE_STATISTICS параметр установлен OFF, система не обновляет статистику, даже если она помечает их как устаревшие. Планы продолжают использовать устаревшие объекты статистики. Установка параметра AUTO_UPDATE_STATISTICS в значение OFF может привести к неоптимальным планам запросов и снижению производительности запросов. Задайте для параметра AUTO_UPDATE STATISTICS значение ON.

• До SQL Server 2014 (12.x) ядро СУБД использует порог перекомпиляции на основе количества строк в таблице или индексированном представлении во время вычисления статистики. Пороговое значение отличается в зависимости от того, является ли таблица временной или постоянной.

  Тип таблицы	Кардинальность таблицы (n)	Пороговое значение повторной компиляции (количество модификаций)
  Temporary	n< 6	6
  Temporary	6 <= n<= 500	500
  Permanent	N<= 500	500
  Временная или постоянная	n> 500	500 + (0,20 * n)

  Например, если таблица содержит 20 000 строк, расчёт составляет 500 + (0.2 * 20,000) = 4,500, а статистика обновляется каждые 4 500 изменений.

• Начиная с SQL Server 2016 (13.x) и с уровнем совместимости базы данных 130, ядро СУБД использует снижение порогового значения перекомпиляции динамической статистики, которая корректируется в соответствии с кратностью таблицы во время вычисления статистики. С этим изменением статистика по большим таблицам обновляется чаще. Однако если база данных имеет уровень совместимости ниже 130, применяются пороговые значения SQL Server 2014 (12.x).

  Тип таблицы	Кардинальность таблицы (n)	Пороговое значение повторной компиляции (количество модификаций)
  Temporary	n < 6	6
  Temporary	6 <= n <= 500	500
  Permanent	n <= 500	500
  Временная или постоянная	n > 500	MIN ( 500 + (0.20 * n), SQRT(1,000 * n) )

  Например, если таблица содержит 2 миллиона строк, результат вычисления — это меньшее из значений 500 + (0.20 * 2,000,000) = 400,500 и SQRT(1,000 * 2,000,000) = 44,721. Это означает, что статистика обновляется каждые 44 721 изменения.

Important

В SQL Server 2008 R2 (10.50.x) — SQL Server 2014 (12.x) включительно либо в SQL Server 2016 (13.x) и более поздних версиях с уровнем совместимости базы данных 120 и ниже включите флаг трассировки 2371, чтобы SQL Server использовал динамически уменьшающийся порог обновления статистики.

Хотя это и рекомендуется для всех сценариев, включение флага трассировки 2371 не является обязательным. Однако вы можете использовать следующие рекомендации по включению флага трассировки 2371 в среде до SQL Server 2016 (13.x):

• Если вы работаете в системе SAP, включите это журналирование. Дополнительные сведения см. в этой статье блога о флаге трассировки 2371.
• Если вам приходится использовать ночное задание для обновления статистики, поскольку текущее автоматическое обновление срабатывает недостаточно часто, рассмотрите включение флага трассировки 2371, чтобы скорректировать порог в зависимости от числа строк в таблице.

Оптимизатор запросов проверяет наличие устаревшей статистики перед компиляцией запроса и до выполнения кэшированного плана запроса. Перед компиляцией запроса оптимизатор запросов использует столбцы, таблицы и индексированные представления в предикате запроса, чтобы определить, какая статистика может быть устаревшей. Перед выполнением кэшированного плана запроса ядро СУБД проверяет, ссылается ли план запроса на статистику up-to-date.

Этот AUTO_UPDATE_STATISTICS параметр применяется к объектам статистики, созданным для индексов, одноколонок в предикатам запросов и статистике, созданной с помощью инструкции CREATE STATISTICS . Этот параметр также применяется к отфильтрованной статистике.

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

AUTO_UPDATE_STATISTICS всегда имеет значение OFF для таблиц, оптимизированных для памяти.

AUTO_UPDATE_STATISTICS_ASYNC

Параметр AUTO_UPDATE_STATISTICS_ASYNC (асинхронное обновление статистики) определяет, какой режим обновления статистики использует оптимизатор запросов: синхронный или асинхронный. По умолчанию параметр асинхронного обновления статистики — OFFи оптимизатор запросов обновляет статистику синхронно. Этот AUTO_UPDATE_STATISTICS_ASYNC параметр применяется к объектам статистики, созданным для индексов, отдельных столбцов в предикатам запросов и статистике, созданной с помощью инструкции CREATE STATISTICS .

Note

Чтобы задать параметр асинхронного обновления статистики в SQL Server Management Studio, на странице «Параметры» окна «Свойства базы данных» установите для параметров «Автоматическое обновление статистики» и «Асинхронное автоматическое обновление статистики» значение True.

Обновление статистики может выполняться синхронно (режим по умолчанию) или асинхронно.

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

• При асинхронном обновлении статистики запросы компилируются с существующей статистикой, даже если она устарела. Если статистика при компиляции запроса является устаревшей, оптимизатор запросов может выбрать неоптимальный план запроса. Как правило, статистика обновляется вскоре после этого. Запросы, которые компилируются после обновления статистики, получают выгоду от использования обновленной статистики.

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

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

• Приложение часто выполняет один и тот же запрос, схожие запросы или схожие кэшированные планы запроса. Асинхронное обновление статистики может обеспечить более прогнозируемое время ответа на запрос по сравнению с синхронным, так как оптимизатор запросов может выполнять входящие запросы, не ожидая появления актуальной статистики. Это устраняет задержку в некоторых запросах, но не влияет на другие запросы.

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

Note

Статистика по локальным временным таблицам всегда обновляется синхронно независимо от AUTO_UPDATE_STATISTICS_ASYNC параметра. Статистика по глобальным временным таблицам обновляется синхронно или асинхронно в соответствии с параметром, заданным AUTO_UPDATE_STATISTICS_ASYNC для пользовательской базы данных.

Обновление асинхронной статистики выполняется с помощью фонового запроса. Когда запрос готов к записи обновленной статистики в базу данных, он пытается получить блокировку изменения схемы для объекта метаданных статистики. Если другой сеанс уже удерживает блокировку того же объекта, обновление асинхронной статистики блокируется до тех пор, пока не появится возможность получить блокировку изменения схемы. Аналогичным образом сеансы, которым для компиляции запроса необходимо получить блокировку стабильности схемы (Sch-S) на объекте метаданных статистики, могут быть заблокированы фоновым сеансом асинхронного обновления статистики, который уже удерживает блокировку изменения схемы или ожидает её получения. Таким образом, для рабочих нагрузок с очень частыми компиляциями запросов и частыми обновлениями статистики, использование асинхронной статистики может повысить вероятность проблем с параллелизмом из-за блокировки.

В База данных SQL Azure Управляемый экземпляр SQL Azure и начиная с SQL Server 2022 г. (16.x) можно избежать потенциальных проблем с параллелизмом с помощью асинхронного обновления статистики, если включить ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITYконфигурацию с областью базы данных. Если эта конфигурация включена, фоновый запрос ожидает получения блокировки изменения схемы (Sch-M) и сохранения обновленной статистики в отдельной очереди с низким приоритетом, что позволяет другим запросам продолжать компиляцию запросов с существующей статистикой. Как только никакой другой сеанс больше не удерживает блокировку объекта метаданных статистики, фоновый запрос получает блокировку на изменение схемы и обновляет статистику. В маловероятном случае, когда фоновый запрос не может получить блокировку в течение нескольких минут, асинхронное обновление статистики прервано, и статистика не обновляется до активации другого автоматического обновления статистики или до обновления статистики вручную.

Note

Параметр конфигурации уровня базы данных ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY доступен в База данных SQL Azure, Управляемый экземпляр SQL Azure и SQL Server, начиная с SQL Server 2022 (16.x).

параметр AUTO_DROP

Область применения: База данных SQL Azure, Управляемый экземпляр SQL Azure и начиная с SQL Server 2022 (16.x)

В SQL Server до SQL Server 2022 (16.x), если вы вручную создаете статистику или используете стороннее средство в пользовательской базе данных, эти объекты статистики могут блокировать или вмешиваться в изменения схемы.

Начиная с SQL Server 2022 (16.x), параметр автоматического удаления включен по умолчанию для всех новых и перенесенных баз данных. Если включить свойство AUTO_DROP, база данных создаёт объекты статистики таким образом, что последующее изменение схемы не блокируется объектом статистики, а статистические объекты при необходимости удаляются. Таким образом, вручную созданная статистика с включенным автоматическим удалением ведет себя как автоматически созданная статистика.

В База данных SQL Azure, Управляемый экземпляр SQL Azure и SQL Server 2022 (16.x), а также в более поздних версиях SQL Server статистика, создаваемая автоматически, всегда ведет себя так, как будто включен параметр AUTO_DROP.

Note

Попытка задать или отменить свойство автоматического удаления в автоматически созданной статистике может вызвать ошибки. Автоматически создаваемая статистика всегда использует автоматическое удаление. Некоторые резервные копии при восстановлении могут неправильно задать это свойство до следующего обновления объекта статистики (вручную или автоматически). Однако автоматически создаваемые статистические данные всегда работают как автоматически удаляемые статистические данные. При восстановлении базы данных в SQL Server 2022 (16.x) из предыдущей версии рекомендуется выполнить sp_updatestats в базе данных, установив соответствующие метаданные для функции автоматического удаления статистики.

Например, чтобы вручную создать объект статистики dbo.DatabaseLog в таблице:

CREATE STATISTICS [mystats]
    ON [dbo].[DatabaseLog]([DatabaseLogID], [PostTime], [DatabaseUser])
    WITH AUTO_DROP = ON;

Например, чтобы обновить параметр автоматического удаления объекта статистики dbo.DatabaseLog в таблице:

UPDATE STATISTICS [dbo].[DatabaseLog] ([mystats])
    WITH AUTO_DROP = ON;

Чтобы оценить параметр автоматического удаления для существующих статистических объектов, используйте столбец auto_drop в sys.stats:

SELECT object_id,
       [name],
       auto_drop
FROM sys.stats;

Дополнительные сведения см. в разделе AUTO_DROP.

INCREMENTAL

Область применения: SQL Server 2014 (12.x) и более поздних версий.

Если задать параметру INCREMENTAL объекта CREATE STATISTICS значение ON, будет создана статистика для каждого раздела. Когда вы устанавливаете это значение в OFF, база данных удаляет дерево статистики и пересчитывает статистику. Значение по умолчанию — OFF. Этот параметр переопределяет свойство уровня INCREMENTAL базы данных.

• Дополнительные сведения о создании добавочной статистики см. в статье CREATE STATISTICS.
• Дополнительные сведения об автоматическом создании статистики для каждого раздела см. в разделе Свойства базы данных (страница «Параметры») и в параметре ALTER DATABASE SET.

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

Если статистика по секциям не поддерживается, база данных игнорирует параметр и создает предупреждение. Добавочные статистические данные не поддерживаются для следующих типов статистики:

• Статистика, созданная с индексами, которые не совпадают с базовой таблицей.
• Статистика, созданная на доступных для чтения вторичных базах данных Always On.
• Статистики, созданные в базах данных, доступных только для чтения.
• Статистики, созданные по фильтрованным индексам.
• Статистика, созданная по представлениям.
• Статистики, созданные по внутренним таблицам.
• Статистики, созданные с пространственными индексами или XML-индексами.

Когда создавать статистику

Оптимизатор запросов самостоятельно создает статистику следующим образом:

1. При создании индекса в таблицах или представлениях оптимизатор запросов создает статистику для индексов. Такая статистика создается по ключевым столбцам индекса. Если индекс является отфильтрованным, оптимизатор запросов создает отфильтрованную статистику по подмножеству строк, которое указано для отфильтрованного индекса. Дополнительные сведения о отфильтрованных индексах см. в разделе "Создание отфильтрованных индексов " и CREATE INDEX.

   Note

   В SQL Server 2014 (12.x) и более поздних версиях база данных не создает статистику путем сканирования всех строк в таблице при создании или перестроении секционированного индекса. Вместо этого оптимизатор запросов использует для создания статистики алгоритм выборки по умолчанию. После обновления базы данных с секционированных индексов вы можете заметить разницу в данных гистограммы для этих индексов. Это изменение в поведении может не повлиять на производительность запросов. Чтобы получить статистику по секционированным индексам, сканируя все строки в таблице, используйте CREATE STATISTICS или UPDATE STATISTICS с предложением FULLSCAN .

2. Если включен параметр AUTO_CREATE_STATISTICS, оптимизатор запросов создает статистику для отдельных столбцов в предикатах запросов.

Для большинства запросов эти два метода для создания статистики обеспечивают высококачественный план запросов. В некоторых случаях можно улучшить планы запросов, создав дополнительную статистику с помощью инструкции CREATE STATISTICS . Эта дополнительная статистика может записывать статистические корреляции, которые оптимизатор запросов не учитывает при создании статистики для индексов или отдельных столбцов. Приложение может иметь дополнительные статистические корреляции в данных таблицы. Если учитывать такие корреляции в объекте статистики, оптимизатор запросов сможет усовершенствовать планы запросов. Например, план запроса можно улучшить путем использования отфильтрованной статистики по подмножеству строк данных или статистики по нескольким столбцам предиката запроса.

При создании статистики с помощью инструкции CREATE STATISTICS оставьте параметр AUTO_CREATE_STATISTICSON, чтобы оптимизатор запросов продолжал регулярно создавать одностолбцовую статистику для столбцов, используемых в предикатах запросов. Дополнительные сведения о предикаатах запросов см. в условии поиска.

Рассмотрите возможность создания статистики с помощью инструкции CREATE STATISTICS, если выполняется любое из следующих условий:

• Помощник по настройке ядра СУБД предлагает создать статистику.
• Предикат запроса содержит несколько коррелированных столбцов, которые еще не являются ключами в одном индексе.
• Запрос выполняет выборку из подмножества данных.
• Для запроса отсутствует статистика.

Note

Сведения, относящиеся к статистике и таблицам, связанным с выполняющейся в памяти OLTP, см. в статье о статистике для таблиц, оптимизированных для памяти.

Предикат запроса содержит несколько коррелированных столбцов

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

Если столбцы уже находятся в одном индексе, объект статистики multicolumn уже существует, и вам не нужно создавать его вручную. Если столбцы еще не в одном индексе, можно создать многоклумную статистику, создав индекс для столбцов или используя инструкцию CREATE STATISTICS . На поддержание индекса расходуется больше системных ресурсов по сравнению с объектом статистики. Если приложению не требуется многоколоннный индекс, вы можете сэкономить системные ресурсы, создав объект статистики без создания индекса.

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

Чтобы получить значения плотности, полезные для оценки количества элементов, столбцы в предикате запроса должны совпадать с одним из префиксов столбцов в определении объекта статистики. Например, в следующем примере создается объект статистики по нескольким столбцам: LastName, MiddleNameи FirstName.

USE AdventureWorks2022;
GO

IF EXISTS (SELECT name
           FROM sys.stats
           WHERE name = 'LastFirst'
                 AND object_ID = OBJECT_ID('Person.Person'))
    DROP STATISTICS Person.Person.LastFirst;
GO

CREATE STATISTICS LastFirst
    ON Person.Person(LastName, MiddleName, FirstName);
GO

В этом примере объект статистики LastFirst содержит значения плотности для префиксов следующих столбцов: (LastName), (LastName, MiddleName) и (LastName, MiddleName, FirstName). Плотность недоступна для (LastName, FirstName). Если запрос использует LastName и FirstName без использования MiddleName, плотность данных недоступна для оценки кардинальности.

Запрос выбирает из подмножества данных

Когда оптимизатор запросов создает статистику по отдельным столбцам и индексам, она создается по значениям во всех строках. Если запросы выполняют выборку из подмножества строк и в этом подмножестве присутствует уникальное распределение данных, то отфильтрованная статистика может улучшить планы запросов. Вы можете создать отфильтрованную статистику с помощью CREATE STATISTICS инструкции с предложением WHERE , чтобы определить выражение предиката фильтра.

Например, с помощью AdventureWorks2025 каждый продукт в таблице принадлежит одной из четырех категорий в Production.ProductProduction.ProductCategory таблице: Bikes, Components, Clothingи Accessories. Каждая из категорий имеет разное распределение данных по весу: вес велосипедов варьируется от 13,77 до 30,0, вес компонентов — от 2,12 до 1050,00, включая некоторые значения NULL, вес одежды — это NULL во всех случаях, а вес аксессуаров также NULL.

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

Следующая инструкция создает отфильтрованную статистику BikeWeights по всем подкатегориям для Bikes. Отфильтрованное выражение предиката определяет велосипеды, выполняя перечисление всех подкатегорий велосипедов со сравнением Production.ProductSubcategoryID IN (1,2,3). Предикат не может использовать имя категории Bikes, так как он хранится в таблице Production.ProductCategory, а все столбцы в выражении фильтра должны находиться в одной таблице.

USE AdventureWorks2022;
GO
IF EXISTS ( SELECT name FROM sys.stats
    WHERE name = 'BikeWeights'
    AND object_ID = OBJECT_ID ('Production.Product'))
DROP STATISTICS Production.Product.BikeWeights;
GO
CREATE STATISTICS BikeWeights
    ON Production.Product (Weight)
WHERE ProductSubcategoryID IN (1,2,3);
GO

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

SELECT P.Weight AS Weight,
       S.Name AS BikeName
FROM Production.Product AS P
     INNER JOIN Production.ProductSubcategory AS S
         ON P.ProductSubcategoryID = S.ProductSubcategoryID
WHERE P.ProductSubcategoryID IN (1, 2, 3)
      AND P.Weight > 25
ORDER BY P.Weight;
GO

Запрос выявляет отсутствующую статистику

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

Отсутствующие статистические данные указываются как предупреждения (имя таблицы в красном тексте) при графическом отображении плана выполнения запроса с помощью SQL Server Management Studio. Кроме того, мониторинг класса событий "Статистика отсутствующих столбцов " с помощью SQL Server Profiler указывает, когда статистика отсутствует. Дополнительные сведения см. в статье Категория событий "Ошибки и предупреждения" (ядро СУБД).

Если статистика отсутствует, выполните следующие действия.

• Убедитесь, что параметры AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS включены.
• Убедитесь, что база данных не доступна только для чтения. Если база данных доступна только для чтения, новый объект статистики не может быть сохранен.
• Создайте недостающую статистику с помощью инструкции CREATE STATISTICS .

Временная статистика

Если статистические данные для базы данных только для чтения или снимка только для чтения отсутствуют или устарели, ядро СУБД создает и поддерживает временную статистику в tempdb. Когда ядро СУБД создает временную статистику, имя статистики добавляется суффиксом _readonly_database_statistic для отличия временной статистики от постоянной статистики. Суффикс _readonly_database_statistic зарезервирован для статистики, созданной ядром СУБД. Скрипты для временной статистики можно создавать и выполнять в базе данных чтения и записи. При выполнении скрипта Management Studio изменяет суффикс имени статистики с _readonly_database_statistic на _readonly_database_statistic_scripted.

Только ядро СУБД может создавать и обновлять временную статистику. Тем не менее можно удалять временную статистику и наблюдать за свойствами статистики с помощью тех же инструментов, которые используются для постоянной статистики:

• Удалите временную статистику с помощью инструкции DROP STATISTICS .
• Мониторинг статистики ведется с помощью представлений каталога sys.stats и sys.stats_columns. Представление системного каталога sys.stats включает столбец is_temporary для указания постоянной и временной статистики.

Так как временная статистика хранится в tempdb, перезапуск ядра СУБД удаляет всю временную статистику.

Как и для всех статистических данных, создание и обновление временной статистики требует изменения схемы (Sch-M) для блокировки объекта. Эта блокировка может блокировать другие запросы и процессы, включая процесс повторного выполнения системы на вторичных репликах, которые применяют транзакции из первичной реплики. Если эта блокировка влияет на рабочие нагрузки запросов или распространение данных, можно отключить автоматическое создание и обновление временной статистики с помощью READABLE_SECONDARY_TEMPORARY_STATS_AUTO_CREATEREADABLE_SECONDARY_TEMPORARY_STATS_AUTO_UPDATEконфигураций с областью базы данных соответственно.

Когда обновлять статистику

Оптимизатор запросов определяет, когда статистика может быть устаревшей, а затем обновляет их при необходимости для плана запроса. В некоторых случаях можно улучшить план запроса и, следовательно, повысить производительность запросов, обновляя статистику чаще, чем при AUTO_UPDATE_STATISTICSON. Статистику можно обновить с помощью UPDATE STATISTICS инструкции или хранимой процедуры sp_updatestats.

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

При обновлении статистики с помощью UPDATE STATISTICS или sp_updatestats оставляйте AUTO_UPDATE_STATISTICS равным ON, чтобы оптимизатор запросов регулярно обновлял статистику.

• Дополнительные сведения об обновлении статистики для столбца, индекса, таблицы или индексированного представления см. в статье UPDATE STATISTICS.

• Информация об обновлении статистики для всех пользовательских и внутренних таблиц в базе данных см. в хранимой процедуре sp_updatestats.

• Дополнительные сведения о пороговых значениях для автоматического обновления статистики см. в статье Параметр AUTO_UPDATE_STATISTICS.

Если задать для AUTO_UPDATE_STATISTICS значение OFF, перекомпиляция плана по-прежнему может происходить по ряду других причин, но автоматически из-за обновления устаревшей статистики она не происходит. Когда для AUTO_UPDATE_STATISTICS задается значение OFF, обновление статистики выполняется только в рамках других процессов, запланированных вручную, таких как планы обслуживания. Поэтому установка значения AUTO_UPDATE_STATISTICS в OFF может привести к неоптимальным планам запросов и ухудшению производительности запросов.

Обнаружение устаревшей статистики

Чтобы определить время последнего обновления статистики, используйте функцию sys.dm_db_stats_properties или STATS_DATE.

Обновление статистики рекомендуется в следующих ситуациях.

• Запросы выполняются медленно.
• Операции вставки выполняются для ключевых столбцов, отсортированных в порядке возрастания или убывания.
• После работ по техническому обслуживанию.

Примеры обновления статистики вручную см. в разделе UPDATE STATISTICS.

Запросы выполняются медленно

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

Операции вставки выполняются в ключевых столбцах, упорядоченных по возрастанию или убыванию

Статистика для ключевых столбцов с возрастающими или убывающими значениями, таких как IDENTITY или столбцы меток времени в реальном времени, может требовать более частого обновления, чем выполняет оптимизатор запросов. Операции вставки добавляют новые значения в столбцы, отсортированные по возрастанию или по убыванию. Число добавляемых строк может оказаться слишком маленьким и не вызвать обновление статистики. Если статистика не up-to-date и запросы выбираются из последних добавленных строк, текущая статистика не имеет оценки кратности для этих новых значений. Это условие может приводить к неточным оценкам кратности и замедлению выполнения запросов.

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

После операций обслуживания

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

Такие операции, как перестроение, дефрагментация или реорганизация индекса, не изменяют распределение данных. Таким образом, вам не нужно обновлять статистику после выполнения операций ALTER INDEX ПЕРЕСТРОЕНИЯ, DBCC DBREINDEX, DBCC INDEXDEFRAG или ALTER INDEX REORGANIZE . Оптимизатор запросов обновляет статистику при перестроении индекса в таблице или представлении с помощью ALTER INDEX REBUILD или DBCC DBREINDEX; однако это обновление статистики является побочным результатом повторного создания индекса. Оптимизатор запросов не обновляет статистику после DBCC INDEXDEFRAG или ALTER INDEX REORGANIZE операций.

Tip

Начиная с SQL Server 2016 (13.x) SP1 CU4, используйте параметр PERSIST_SAMPLE_PERCENT в CREATE STATISTICS или UPDATE STATISTICS, чтобы задать и сохранить определенный процент выборки при последующих обновлениях статистики, если в них явно не указан процент выборки.

Автоматическое управление индексами и статистикой

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

Определение статистики используемого оптимизатора запросов

Вы можете найти объекты статистики, которые оптимизатор запросов использует при компиляции запроса, проверяя предполагаемый или фактический план выполнения. При просмотре плана выполнения элемент OptimizerStatsUage содержит элементы StatisticsInfo, в которых содержатся сведения об объектах статистики, загруженных оптимизатором запросов во время компиляции. Элементы StatisticsInfo содержат имя объекта статистики, базу данных, схему и таблицу, к которой она принадлежит, количество изменений во время компиляции, процент выборки и время последнего обновления.

Используйте любой из следующих методов для проверки плана выполнения:

• В SQL Server Management Studio выберите "Включить фактический план выполнения" (CTRL+M) перед выполнением запроса. На вкладке "План выполнения ", которая отображается с результатами, можно:
  • Щелкните правой кнопкой мыши графический план и выберите "Показать XML-код плана выполнения". Найдите элемент OptimizerStatsUsage и каждый его дочерний элемент StatisticsInfo.
  • Выберите последний (левый) оператор. (В случае SELECT запроса этот оператор является SELECT узлом.) В окне "Свойства" разверните узел OptimizerStatsUsage и просмотрите сведения о объектах статистики, используемых в запросе.
• Запустите SETSET STATISTICS XML ON перед запросом. Выберите гиперссылку, которая отображается с результатами, чтобы просмотреть XML-код плана выполнения.
• Запрос sys.dm_exec_query_plan или sys.dm_exec_query_statistics_xml для последних запросов.
• Прочитайте ранее сохранённый план из хранилища хранилище запросов с помощью sys.query_store_plan.

Каждый StatisticsInfo элемент выглядит следующим фрагментом XML из запроса в образце AdventureWorks2022 базы данных:

<StatisticsInfo 
    Database="[AdventureWorks2022]" 
    Schema="[Sales]" 
    Table="[SalesOrderDetail]" 
    Statistics="[IX_SalesOrderDetail_ProductID]" 
    ModificationCount="0" 
    SamplingPercent="100" 
    LastUpdate="2025-09-07T15:32:16.89" />

Атрибут	Значение
Database, Schema, Table	Объект, к которому относится статистика.
Statistics	Имя объекта статистики в базе данных. Используйте это имя с dbCC SHOW_STATISTICS или sys.stats для проверки гистограммы и вектора плотности.
ModificationCount	Количество изменений данных после последнего обновления статистики в момент компиляции плана. Большое значение относительно размера таблицы указывает, что статистика была устаревшей во время компиляции.
SamplingPercent	Процент строк, выборочных для построения статистики. Более низкие значения могут создавать менее точные гистограммы для искаженных данных.
LastUpdate	Метка времени последнего обновления статистики. Если параметр AUTO_UPDATE_STATISTICS включен в базе данных, база данных автоматически обновляет статистику при необходимости.

Note

StatisticsInfo отражает статистику, доступную и учитываемую во время компиляции плана. StatisticsInfo Если запись отсутствует для столбца фильтров запросов, оптимизатор запросов не определил соответствующую статистику, которая является потенциальным источником плохой производительности.

Чтобы проверить текущую свежесть и количество изменений для объекта статистики, используйте sys.dm_db_stats_properties. Например, следующий запрос предоставляет текущие метрики для объекта статистики, именованного IX_SalesOrderDetail_ProductID в таблице Sales.SalesOrderDetail:

SELECT
    OBJECT_SCHEMA_NAME(s.object_id) AS schema_name,
    OBJECT_NAME(s.object_id)        AS table_name,
    s.name                          AS statistics_name,
    sp.last_updated,
    sp.rows,
    sp.rows_sampled,
    sp.modification_counter
FROM sys.stats AS s
OUTER APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp
WHERE s.object_id = OBJECT_ID(N'Sales.SalesOrderDetail')
  AND s.name = N'IX_SalesOrderDetail_ProductID';

Чтобы определить, включены ли автоматические параметры создания и обновления текущей базы данных, используйте следующую команду:

SELECT [name],
    is_auto_create_stats_on,
    is_auto_update_stats_on,
    is_auto_update_stats_async_on
FROM sys.databases
WHERE [name] = DB_NAME();

Запросы, использующие статистику эффективно

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

Вы можете улучшить планы запросов, следуя рекомендациям по разработке запросов, которые помогают эффективно использовать статистику для повышения точности оценок кратности выражений, переменных и функций, используемых в предикатах запросов. Если оптимизатор запросов не знает значения выражения, переменной или функции, он не знает, какое значение следует искать в гистограмме и поэтому не может получить лучшую оценку кратности из гистограммы. Вместо этого оптимизатор запросов основывает оценку кардинальности на среднем числе строк для каждого отдельного значения по всем строкам, включённым в выборку и представленным в гистограмме. Эта ситуация приводит к неоптимальным оценкам кардинальности и может негативно сказаться на производительности запросов. Дополнительные сведения об гистограммах см. в разделе гистограммы в этой статье или sys.dm_db_stats_histogram.

Следующие рекомендации описывают, как писать запросы, чтобы улучшить планы выполнения запросов за счёт улучшения оценок кардинальности.

Улучшить оценки кардинальности для выражений

Чтобы улучшить оценки кратности для выражений, следуйте этим рекомендациям.

• По возможности упростите выражения, содержащие константы. Оптимизатор запросов не оценивает все функции и выражения, содержащие константы перед определением оценки кратности. Например, следует упростить выражение ABS(-100) до 100.
• Если выражение использует несколько переменных, попробуйте создать вычисляемый столбец для выражения, а затем создать статистику или индекс в вычисляемом столбце. Например, для предиката запроса WHERE PRICE + Tax > 100 можно получить более точную оценку кратности, если создать вычисляемый столбец для выражения Price + Tax.

Улучшение оценки кратности для переменных и функций

Чтобы улучшить оценки кратности переменных и функций, выполните следующие рекомендации.

• Если в предикате запроса используется локальная переменная, рекомендуется переписать запрос так, чтобы вместо локальной переменной в нем использовался параметр. Оптимизатор запросов не знает значение локальной переменной при создании плана выполнения запроса. Когда запрос использует параметр, оптимизатор запросов использует оценку кратности для первого фактического значения параметра, которое получает хранимая процедура.

• Рекомендуется использовать стандартную таблицу или временную таблицу для хранения результатов многозначных табличных функций. Оптимизатор запросов не создает статистику для многооператорных табличных функций. С помощью этого подхода оптимизатор запросов может создавать статистику по столбцам таблицы и использовать их для создания лучшего плана запроса.

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

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

  Например, следующая хранимая процедура Sales.GetRecentSales изменяет значение параметра @date, когда @date имеет значение NULL.

  USE AdventureWorks2022;
  GO
  
  IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
      DROP PROCEDURE Sales.GetRecentSales;
  GO
  
  CREATE PROCEDURE Sales.GetRecentSales
  @date DATETIME
  AS
  BEGIN
      IF @date IS NULL
          SET @date = DATEADD(MONTH, -3,
              (SELECT MAX(ORDERDATE)
              FROM Sales.SalesOrderHeader));
      SELECT *
      FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
      WHERE h.SalesOrderID = d.SalesOrderID
          AND h.OrderDate > @date;
  END
  GO
  

  Если первый вызов хранимой процедуры Sales.GetRecentSales передает NULL для параметра @date, оптимизатор запросов компилирует хранимую процедуру с оценкой кардинальности для @date = NULL, даже когда предикат запроса не вызывается с @date = NULL. Эта оценка кратности может значительно отличаться от количества строк в фактическом результате запроса. В итоге оптимизатор запросов может выбрать неоптимальный план запроса. Чтобы избежать этой проблемы, можно переписать хранимую процедуру на две процедуры следующим образом:

  USE AdventureWorks2022;
  GO
  
  IF OBJECT_ID('Sales.GetNullRecentSales', 'P') IS NOT NULL
      DROP PROCEDURE Sales.GetNullRecentSales;
  GO
  
  CREATE PROCEDURE Sales.GetNullRecentSales
  @date DATETIME
  AS
  BEGIN
      IF @date IS NULL
          SET @date = DATEADD(MONTH, -3,
              (SELECT MAX(ORDERDATE)
              FROM Sales.SalesOrderHeader));
      EXECUTE Sales.GetNonNullRecentSales @date;
  END
  GO
  
  IF OBJECT_ID('Sales.GetNonNullRecentSales', 'P') IS NOT NULL
      DROP PROCEDURE Sales.GetNonNullRecentSales;
  GO
  
  CREATE PROCEDURE Sales.GetNonNullRecentSales
  @date DATETIME
  AS
  BEGIN
      SELECT *
      FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
      WHERE h.SalesOrderID = d.SalesOrderID
          AND h.OrderDate > @date;
  END
  GO
  

Повысьте точность оценок кратности с помощью подсказок для запросов

Чтобы улучшить оценки кардинальности для локальных переменных, используйте подсказки запроса OPTIMIZE FOR <value> или OPTIMIZE FOR UNKNOWN вместе с RECOMPILE. Дополнительные сведения см. в подсказках к запросам.

Для некоторых приложений повторная компиляция запроса при каждом выполнении может занять слишком продолжительное время. Указание запроса OPTIMIZE FOR может повысить производительность даже в случае, когда параметр RECOMPILE не используется. Например, можно добавить параметр OPTIMIZE FOR к хранимой процедуре Sales.GetRecentSales, чтобы указать определенную дату. В следующем примере к процедуре OPTIMIZE FOR добавляется параметр Sales.GetRecentSales.

USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetRecentSales;
GO

CREATE PROCEDURE Sales.GetRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID AND h.OrderDate > @date
    OPTION (OPTIMIZE FOR (@date = '2004-05-01 00:00:00.000'));
END
GO

Улучшение оценки кардинальности с помощью подсказок плана

Для некоторых приложений рекомендации по проектированию запросов могут не применяться, так как невозможно изменить запрос или указание запроса RECOMPILE может вызвать слишком много перекомпиляций. Используйте путеводители по планам, чтобы задать другие подсказки, например USE PLAN, для управления поведением запроса при анализе изменений в приложении совместно с поставщиком приложения. Дополнительные сведения о путеводителях по планам см. в разделе Путеводители по планам.

В База данных SQL Azure рассмотрите возможность использования подсказок хранилище запросов для принудительного применения планов вместо plan guides. Дополнительные сведения см. в разделе Указания хранилища запросов.

Связанный контент

• Статистика для таблиц, оптимизированных для памяти
• CREATE STATISTICS (Transact-SQL)
• UPDATE UPDATE STATISTICS (Transact-SQL)
• sp_updatestats (Transact-SQL)
• DBCC SHOW_STATISTICS (Transact-SQL)
• ALTER DATABASE SET параметры (Transact-SQL)
• DROP STATISTICS (Transact-SQL)
• CREATE INDEX (Transact-SQL)
• ALTER INDEX (Transact-SQL)
• создание отфильтрованных индексов
• STATS_DATE (Transact-SQL)
• sys.dm_db_stats_properties (Transact-SQL)
• sys.dm_db_stats_histogram (Transact-SQL)
• sys.stats
• sys.stats_columns (Transact-SQL)
• адаптивный индекс дефрагментировать