Коли краще створити СТАТИСТИКУ замість створення індексу?

Я знайшов багато інформації про те STATISTICS , що таке : як вони підтримуються, як їх можна створити вручну або автоматично з запитів чи індексів тощо. Але я не зміг знайти жодних вказівок чи "найкращих практик" щодо того, колидля їх створення: які ситуації отримують більше вигоди від створеного вручну об’єкта STATISTICS, ніж від індексу. Я бачив створену вручну відфільтровану статистику, яка допомагає запитам на розділених таблицях (адже статистика, створена для індексів, охоплює всю таблицю і не є розділом - brillaint!), Але, безумовно, повинні бути інші сценарії, які мали б користь від об'єкта статистики, тоді як не потребує деталізації індексу, не варто витрачати на підтримку індексу або збільшувати шанси на блокування / глухий замок.

@JonathanFite у коментарі згадав про різницю між індексами та статистикою:

Індекси допоможуть SQL швидше знаходити дані, створюючи підходи, які сортуються інакше, ніж сама таблиця. Статистика допомагає SQL визначити, скільки пам'яті / зусиль буде потрібно для задоволення запиту.

Це чудова інформація, головним чином тому, що вона допомагає мені уточнити моє питання:

Як знання цього (або будь-яка інша технічна інформація на те , що S і як и , пов'язане з поведінкою і характером STATISTICS) допоможе визначити , коли вибрати CREATE STATISTICSбільш CREATE INDEX, особливо при створенні індексу буде створити відповідний STATISTICSоб'єкт? Який сценарій краще використовувати, якщо мати лише інформацію про СТАТИСТИКУ та не мати Індекс?

Було б дуже корисно, якщо можливо, мати робочий приклад сценарію, коли STATISTICSоб'єкт краще підходить, ніж an INDEX.

Оскільки я є візуальним учнем / мислителем, я вважав, що це може допомогти побачити відмінності між собою STATISTICSта INDEXes, поруч, як можливий засіб допомогти визначити, коли 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, ми були занадто сором'язливими для запитання

Статистика. Чи можливі багатоколінні гістограми?

** Щоб було зрозуміло, у мене немає відповіді на це, і я насправді шукаю отримати зворотній зв'язок від кількох людей, щоб надати інформацію, яка, як видається, дивно відсутня тут, в інтерв'ю.

Ви запитуєте, що обертається навколо - коли добре створити статистику проти створення індексу (який створює статистику).

З мого SQL SERVER Internals приміток (SQLSkills class- IE1 і IE2) і SQL Server Нутрощі бронювання , нижче моє обмежене розуміння:

Статистика SQL Server - це не що інше, як системні об'єкти, які містять життєво важливу інформацію про значення ключових індексів та звичайні значення стовпців.

SQL Server використовує модель на основі витрат, щоб якомога швидше вибрати "досить хороший" план виконання. Оцінка Cardanility (оцінка кількості рядків, що підлягають обробці на кожному етапі виконання запиту) - найважливіший фактор оптимізації запитів, який впливає на стратегію приєднання, вимогу надання пам’яті, вибір робочих ниток, а також вибір індексів під час доступу до даних .

SQL Server не використовує некластеризовані індекси, коли вважає, що великого немає. операцій із пошуку ключа KEY або RID знадобиться, тому він веде статистику щодо індексів (і стовпців), що допоможе в таких оцінках.

Про статистику є дві важливі речі:

1. Гістограма зберігає інформацію про розподіл даних для самого лівого стовпчика статистики (індексу). Він також зберігає інформацію про багатостовпну щільність ключових значень. Таким чином, гістограма зберігає розподіл даних лише для крайнього лівого стовпця статистики.

2. SQL Server збереже не більше 200 кроків у гістограмі незалежно від розміру таблиці. Інтервали, охоплені кожним кроком гістограми, збільшуються в міру зростання таблиці, що призводить до "менш точної" статистики для великих таблиць.

   Пам'ятайте, що вибірковість індексу - це показник, обернено пропорційний щільності, тобто чим більше унікальних значень стовпчик, тим вища його селективність.

Коли конкретні запити не запускаються дуже часто, ви можете створити статистику на рівні стовпців, а не індекс. Статистика на рівні стовпців допомагає Оптимізатору запитів знайти кращі плани виконання, хоча ці плани виконання є неоптимальними через залучені сканування індексів. У той же час статистика не додає накладних витрат під час операцій із зміни даних, і це допомагає уникнути обслуговування індексу. Цей підхід працює лише для рідко виконуваних запитів.

Посилання:

• Статистика стовпців Дайте оптимізатору край від Калена Делані
• Статистика, прокляті брехні та статистика - що таке Статман? автор Конор Каннінгем

Примітка. Хтось, як Пол Уайт або Аарон Бертран, може задзвонити, щоб надати більше кольорів вашому хорошому запитанню .

Я б сказав, що вам потрібен індекс, коли вам потрібно мати можливість обмежити кількість даних / швидко дістатись до правильних даних на основі полів.

Вам потрібна статистика, коли вам потрібен оптимізатор, щоб зрозуміти природу даних, щоб мати можливість виконувати операції найкращим чином.

Як я зрозумів, відфільтрована статистика допомагає, коли у вас є недоліки у ваших даних, які сильно впливають на план, наприклад, при переповненні стека небагато користувачів мають величезну кількість повідомлень, тому використання просто середніх повідомлень на користувача не є найкращою оцінкою. Таким чином, ви можете створити відфільтровану статистику на userId на основі імені користувача, і тоді SQL Server повинен знати, що коли це ім’я користувача знаходиться в запиті, це ідентифікатор користувача, який він отримає, і він повинен мати можливість з'ясувати, що індексоване поле в таблиці повідомлень матиме величезну кількість рядків з цим ідентифікатором, оскільки там існує гістограма. З середніми показниками цього зробити неможливо.

З 70-461 навчальна книга Іціка Бен-Гана

Існує лише кілька можливих причин створення статистики вручну. Один із прикладів - коли предикат запиту містить кілька стовпців, які мають взаємозв'язки між стовпцями; статистика щодо кількох стовпців може допомогти покращити план запитів. Статистика кількох стовпців містить щільність між стовпцями, яка недоступна в статистиці про один стовпчик. Однак якщо стовпці вже в одному індексі, об'єкт статистики багатокольонок уже існує, тому не слід створювати додатковий вручну.