Я нашел много информации о том, что STATISTICS
: как они поддерживаются, как их можно создавать вручную или автоматически из запросов или индексов и так далее. Но я не смог найти каких-либо указаний или информации о «наилучших методах» в отношении того, когдадля их создания: какие ситуации выигрывают больше от созданного вручную объекта STATISTICS, чем от Index. Я видел созданные вручную отфильтрованные статистические данные, помогающие выполнять запросы к многораздельным таблицам (потому что статистика, созданная для индексов, охватывает всю таблицу, а не для каждого раздела - отличная информация!), Но, безусловно, должны существовать другие сценарии, которые выиграли бы от объекта статистики, пока не нуждаются в детализации индекса и не стоят затрат на его обслуживание или увеличение шансов на блокировку / взаимоблокировку.
@JonathanFite в комментарии упомянул различие между индексами и статистикой:
Индексы помогут SQL быстрее находить данные, создавая запросы, которые сортируются не так, как сама таблица. Статистика помогает SQL определить, сколько памяти / усилий потребуется для выполнения запроса.
Это отличная информация, в основном потому, что она помогает мне уточнить мой вопрос:
Как знание этого (или любая другая техническая информация на то , что S и как ы , связанное с поведением и характером STATISTICS
) поможет определить , когда выбрать CREATE STATISTICS
более CREATE INDEX
, особенно при создании индекса будет создать соответствующий STATISTICS
объект? Какой сценарий будет лучше обслуживать, имея только информацию STATISTICS и не имея индекса?
Было бы очень полезно, если это возможно, иметь рабочий пример сценария, в котором STATISTICS
объект лучше подходит, чем объект INDEX
.
Так как я визуальный ученик / мыслитель, я подумал, что это может помочь увидеть различия между ними STATISTICS
и INDEX
рядом, как возможное средство, помогающее определить, когда STATISTICS
лучший выбор.
Thingy PROs CONs
------- ---------- -------------------
INDEX * Can help sorts. * Takes up space.
* Contains data (can * Needs to be maintained (extra I/O).
"cover" a query). * More chances for blocking / dead-locks.
STATISTICS * Takes up very little space. * Cannot help sorts.
* Lighter maintenance / won't * Cannot "cover" queries.
slow down DML operations.
* Does not increase chances
of blocking / dead-locks.
Ниже приведены некоторые ресурсы, которые я нашел во время поиска этого, тот, который даже задает тот же вопрос, но на него не было ответа:
Индекс SQL Server против статистики
Вопросы статистики SQL Server, которые мы стеснялись задавать
Статистика. Возможны ли многоколонные гистограммы?
** Чтобы быть ясным, у меня нет ответа на этот вопрос, и я на самом деле хочу получить обратную связь от, надеюсь, нескольких человек, чтобы предоставить то, что, как ни странно, отсутствует информация здесь, в сети.