Non Clustered Index
- Може використовуватися багато разів за столом
- Швидше для операцій вставки і оновлення, ніж кластерізованний індекс
Обидва типи індексу покращують продуктивність при виборі даних з полями, які використовують індекс, але уповільнюють операції оновлення і вставки.
Через повільну вставки і оновлення кластерні індекси повинні бути встановлені в поле, яке зазвичай є інкрементального, тобто Id або Timestamp.
SQL Server зазвичай використовує індекс тільки в тому випадку, якщо його селективність вище 95%.
відповідь дан Martynnw 22 травня '17 о 9:17
Вам не потрібно турбуватися про те, що таке x. Все, що вам потрібно знати - це те, що програму з мільйонами користувачів x буде значним - Pacerier 22 травня '17 о 9:17
Є також міркування щодо зберігання. При вставці рядків в таблицю без кластерізованного індексу рядка зберігаються на одній сторінці впритул, а оновлення рядка може привести до переміщення рядка в кінець таблиці, залишивши порожній простір і фрагментируя таблицю і індекси. - Jeremiah Peschka 22 травня '17 о 9:17
@StephaniePage: Цікаво, як буде вимірюватися ця «вибірковість»? Індекс, який має одне значення для 999 900 записів і одне значення для 100, може бути дуже корисним, якщо тільки він коли-небудь використовує його для пошуку 100. - supercat 22 травня '17 о 9:17
Ідея про те, що 95% записів повинна бути унікальною, - це помилка. Припустимо, у вас є таблиця з 1,000,000 рядками, і ви індексуєте стовпець з 500,000 ключами. 0% унікальні, але кожен ключ повертає 2 з мільйона рядків. Цей індекс абсолютно корисний незалежно від того, що 0% записів унікальні. - Stephanie Page 22 травня '17 о 9:17
Наприклад, якби хтось починав з порожньою некластерние бази даних і додавав 10 000 записів у випадковій послідовності, записи, ймовірно, додаються в кінці в тому порядку, в якому вони були додані. Читання бази даних по порядку за індексом зажадає 10000 одноразових читань. Однак, якщо використовувати кластерну базу даних, система може перевіряти, додається чи кожен запис, якщо попередній запис зберігалася сама по собі; Якщо він виявив, що так воно і є, він може написати цей запис з новою в кінці бази даних. Потім він міг би подивитися фізичну запис перед слотами, в яких знаходилися переміщені записи, і подивитися, чи була збережена запис, яка послідувала за нею, сама по собі. Якщо він виявив, що так воно і є, він може перенести цей запис на це місце. Використання такого підходу призвело б до того, що багато записів групувалися б попарно, що потенційно майже подвоювало б швидкість послідовного читання.
відповідь дан supercat 22 травня '17 о 9:17
Групові індекси відмінно працюють для діапазонів (наприклад, select * from my_table, де my_key знаходиться між @min і @max)
У деяких випадках СУБД не потрібно буде виконувати сортування, якщо ви використовуєте інструкцію orderby.
Групові індекси можуть уповільнювати вставки, тому що фізичні макети записів повинні змінюватися в міру введення записів, якщо нові ключі розташовані не в послідовному порядку.
відповідь дан Giovanni Galbo 22 травня '17 о 9:17
Кластерізованний індекс по суті є відсортованої копією даних в індексованих стовпцях.
Основною перевагою кластерного індексу є те, що коли ваш запит (пошук) знаходить дані в індексі, то для вилучення цих даних не потрібно додаткове введення-виведення.
Накладні витрати на підтримку кластерізованного індексу, особливо в часто оновлюваної таблиці, можуть призвести до низької продуктивності, і з цієї причини може бути краще створити некластерізованний індекс.
відповідь дан Ed Guiness 22 травня '17 о 9:17
Кластерізованний індекс фактично описує порядок, в якому записи фізично зберігаються на диску, тому у вас може бути тільки один.
Некластерізованний індекс визначає логічний порядок, який не відповідає фізичній замовлення на диску.
відповідь дан Josh 22 травня '17 о 9:17