У нашій базі даних MS SQL я запускав інструмент автоматичного індексування (я змінив сценарій від Microsoft, який розглядає таблиці статистичних даних індексу - Автоматизована автоматична індексація ). Зі статистики, тепер у мене є список рекомендацій щодо індексів, які потрібно створити.

Редагувати: Описані вище індекси беруть інформацію з DMV, яка розповідає про те, що двигун бази даних використовував би індекси, якщо вони були б доступні, а сценарії приймають рекомендації Top x (за пошуками, впливом користувачів тощо) і складають їх у таблицю.

(Редагуйте вище частково взято з відповіді Ларрі Коулмана нижче, щоб уточнити, що роблять сценарії)

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

Чи потрібно запускати SQL Profiler або краще вивчити код, який запитує таблиці? А у вас є якісь інші поради?

Я використовую сценарії аналізу індексу Джейсона Страте (Старе місце) . Вони говорять про те, як багато ваших існуючих індексів, а також скільки відсутніх індексів було б використано. Зазвичай я не додаю індекси, якщо вони не складають більше 5 або 10% запитів у таблиці.

Найголовніше, однак, це про те, щоб переконатися, що програма реагує досить швидко для користувачів.

Оновлення: статті блогу аналізу індексу Джейсона Страте для новіших сценаріїв (Нове місце)

Подвійне оновлення: У цей час я використовую sp_BlitzIndex® під час аналізу індексу.

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

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

Зазвичай операції пошуку є більш ефективними, ніж сканування, завдяки фізичному запиту меншого набору даних. Бувають ситуації, коли це не так, наприклад, дуже невеликий початковий набір даних, але це виходить за рамки вашого питання.

Тепер ви запитали, як визначити, наскільки ефективний індекс, і слід пам’ятати про кілька речей. Ключові стовпчики кластеризованого індексу називаються ключем кластеризації. Ось як записи робляться унікальними в контексті кластерного індексу. Усі некластеризовані індекси за замовчуванням включають кластерний ключ, щоб виконувати пошук при необхідності. Всі індекси будуть вставлені до, оновлені або видалені з кожного відповідного оператора DML. Зважаючи на це, найкраще врівноважувати підвищення продуктивності у вибраних операторах та показниках ефективності в операторах вставлення, видалення та оновлення.

Для того, щоб визначити, наскільки ефективний індекс, ви повинні визначити вибірковість своїх індексних ключів. Селективність можна визначити у відсотках від різних чітких записів до загальних записів. Якщо у мене є таблиця [person] зі 100 загальними записами, а стовпець [first_name] містить 90 різних значень, можна сказати, що стовпець [first_name] є 90% вибірковим. Чим вище селективність, тим ефективніше індексний ключ. Маючи на увазі вибірковість, найкраще спочатку помістити свої найбільш селективні стовпці в індексний ключ. Використовуючи мій попередній приклад [person], що робити, якщо у нас був стовпець [прізвище], який на 95% був вибірчим? Ми хотіли б створити індекс із [last_name], [first_name] як індексний ключ.

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

Нещодавно я відкрив для людей BrentOzar Unltd фантастичний безкоштовний сценарій http://www.brentozar.com/blitzindex/

Це дає хороший аналіз того, які індекси існують, як часто вони використовуються і як часто система запитів шукає індекс, який не існує.

Це керівництво, як правило, добре. Іноді це стає трохи завищеним щодо ідей. Я, як правило, робив наступне:

• Видалені індекси, які НІКОЛИ не читалися (а може і менше, ніж 50 разів на місяць).
• Додано найочевидніші індекси зовнішніх ключів та полів, які я знаю, ми використовуємо багато.

Я не додав усіх рекомендованих індексів і повернувся через тиждень, щоб побачити, що вони більше не рекомендуються, оскільки система запитів використовує деякі інші нові індекси замість цього!

Як правило, вам слід уникати індексів на:

• Дуже невеликі таблиці (менше 50 до 200 записів): часто механізм запитів швидше, якщо він сканує таблицю, а не завантажує індекс, читає, обробляє його і т.д.
• Уникайте індексів на стовпці з низькою кардинальністю ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) у першому згаданому стовпці. Наприклад, індексація гендерного поля (M / F) дуже корисна, так само практично, як сканувати таблицю і знайти ~ 50%, що відповідає. Якщо він вказаний після чогось більш конкретного в індексі (наприклад, [дата народження, стать]), це краще - ви можете захотіти всіх чоловіків, народжених за певний проміжок часу.

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

Я скоротив деякі таблиці з 900MB до 400MB, тільки тому, що вони були заздалегідь неструктуровані купи. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Реорганізувати / відновити

Вам слід шукати, щоб перевірити наявність фрагментованих індексів. Трохи фрагментації все в порядку, не будьте нав’язливими! http://technet.microsoft.com/en-us/library/ms189858.aspx Знайте різницю між перебудовою та перебудовою!

Регулярно переглядайте

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

Як багато

У недавньому відео Brent рекомендує (як правило) не більше 5 індексів на столі з великою кількістю записів (наприклад, таблиця замовлень), і не більше 10, якщо вона читається набагато більше, ніж написана (тобто таблиця реєстрації для аналітики) http: / /www.youtube.com/watch?v=gOsflkQkHjg

Загалом

Це залежить!

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

Сподіваюся, це допомагає!

Зазвичай можна виконати конкретне навантаження (запити) і ретельно перевірити вплив кожного нового індексу на навантаження. Цей ітераційний процес завжди повинен включати ретельний аналіз планів виконання, який би виявив, які індекси використовуються. Тема аналізу запиту є тривалою, і починати з спеціальної глави MSDN Аналіз запиту - це хороша ставка.

Іноді, коли навантаження занадто складна або знання дизайну баз даних є схематичним, користується Радником по настройці двигуна баз даних , який робить деякий автоматичний аналіз вашої завантаженості та пропонує деякі показники. Пропозиції, звичайно, повинні бути ретельно проаналізовані, а вплив слід негайно виміряти.

Тож якщо ви слідуєте моїй ідеї, додавання індексу та вимірювання впливу насправді є лише випадком тестування A / B : ви запускаєте навантаження без індексу як базову лінію, а потім запускаєте його з індексом, вимірюєте та порівнюєте з базовою лінією, а потім на основі спостережуваних та виміряних показників вирішуйте, чи вплив буде сприятливим. Навантаження є найкращим тестовим набором хорошої якості, але це також може бути повтором захопленого навантаження, див. Як: Повторити файл сліду .

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

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

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

^{Дивіться також: офіційні документи MS DMV}

Це залежить від того, як використовується ця таблиця. Наприклад, скажімо, що у мене є таблиця, яку читають багато разів, але оновлення та вставки рідкісні. Плюс, я завжди запитую таблицю в колонці з іноземним ключем. Буде доцільно створити (некластеризований) індекс над цим зовнішнім ключем, щоб пришвидшити запити читання. Але недоліком є ​​те, що ваша вставка та оновлення стануть повільними.

Є кілька запитів статистики, які вказують, скільки часу займає запит. Почніть з найповільніших. Якщо предикат запиту не має індексу, допоможе створити його.