Групові індекси на основі guid

Відео: Коли варто створювати індекс?

непослідовність GUID

За замовчуванням GUID не є послідовними, і в цьому полягає причина виникнення проблеми фрагментації. В якості ілюстрації розглянемо код, наведений у лістингу 1, який реалізує завантаження записів в таблицю, де стовпчик GUID використовується в якості ключа кластерізованного індексу і обмеження первинного ключа. Якщо вставити рядки в таблицю (кожний рядок закінчується після досягнення довжини в 1 000 байт з використанням наведених вище типів даних), ми отримаємо результати виклику sys.dm_db_ index_physical_stats (див. Лістинг 2 і екран 1).


Вже з самого початку ми спостерігаємо майже стовідсоткову фрагментацію просто за рахунок застосування GUID, а не послідовного процесу з використанням цілих або довгих цілих чисел в Автоінкрементний режимі через властивість IDENTITY шпальти таблиці. Щоб побачити, наскільки швидко індекс на основі GUID стає фрагментованим, повернемося в початок. Усічений таблицю і виконаємо введення 8 записів. Стан фрагментації після введення перших 8 записів показано на екрані 2. Цього і слід було ожідать- проте нам ще належить заповнити сторінку. Що станеться, якщо додати ще один запис, ми бачимо на екрані 3.

Після введення 9-й записи настає розбиття першої сторінки. Так як GUID надходять в кластерізованний індекс непослідовно, сторінки будуть розбиватися, щоб збалансувати вміст (приблизно порівну). У таблиці 9 рядків, тому рівного розбиття бути не може. Що буде, якщо додати ще два рядки? Оскільки сторінки заповнені лише на 55%, а ми знаємо, що на сторінці поміщається 9 рядків, після цього додавання ми повинні як і раніше мати дві сторінки на рівні листя індексу, чи не так (див. Екран 4)?





Однак ми отримали ще одне розбиття сторінки всього лише після додавання двох рядків. Простір витрачається неекономно, і при тому, що використовуються 16-розрядні GUID, а не 4-байтниє INT або 8-байтниє BIGINT, і навіть не дивлячись на те, що зазначений стовідсотковий коефіцієнт заповнення індексу, ми не досягли цієї позначки ні перед першим, ні перед другим розбивкою сторінки. Проведемо останній експеримент.




Отже, у нас є три сторінки індексів, заповнені приблизно на 50%. Ми знаємо, що на сторінці вміщується дев`ять рядків і заданий коефіцієнт заповнення 100%. Теоретично повинна існувати можливість вставити 12 рядків: (50% від 9 округляем до 4, так як не можна вставити половину записи, і множимо на 3). Як ми вже зрозуміли, ймовірність 99% заповнення цих трьох сторінок надзвичайно мала без перестроювання індексів, тому питання лише в тому, наскільки сильно буде фрагментуватися індекс. З`ясуємо це.


Додавши ще 12 рядків в таблицю, отримуємо результат, показаний на екрані 5. Дивно! Додавання двох рядків, 2/11 від загального їх числа, викликало розбиття сторінки, тобто додавання ще однієї сторінки на рівні листя індексу. Додавання ще 12 рядків, тобто 12/23 від загального їх числа, також викликало розбиття сторінки, але тільки одне, хоча частка сторінок, доданих в цілому, в цьому випадку була набагато більше, ніж при додаванні 10-й і 11-й рядків , в результаті якого ми здобули другу розбиття.

Проведемо ще один маленький експеримент: усічений таблицю і знову додамо 23 рядки. Оскільки використовується команда GO #, рядки додаються в рамках одиничних транзакцій. Виводяться результати виклику sys.dm_db_index_ physical_stats після вставки 8-й, 9-й, 11-й і 23-й рядків. Оскільки ми проходимо весь процес заново, повинні вийти аналогічні результати (див. Лістинг 3 і екран 6).

По крайней мере, результати близькі. З огляду на випадкової природи значень GUID, вийшла більш сприятлива картина фрагментації всередині сторінок-число рядків на сторінках залишилося незмінним. Відповідно загальна середня ступінь заповнення сторінок не ізменілась- на даному етапі індекс залишається чотирьохсторінкових. Отже, виконання сценарію з урізанням таблиці і повторним завантаженням 23 рядків все ж призводить до зміни числа сторінок індексу і картини фрагментації. Я зробив це кілька разів і спостерігав середню ступінь фрагментації 50 або 75% на чотирьох сторінках рівня листя, заповнених приблизно на 71%, але також отримав індекс з п`ятьма сторінками на рівні листя з 40-відсотковою середнім ступенем фрагментації, тобто 57-процентним середнім заповненням. Іншими словами, в наявності послідовна непослідовність. Я - адміністратор бази даних (DBA) і терпіти не можу послідовно непослідовних речей.