Чому мої некластеризовані індекси використовують більше місця під час видалення рядків?

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

Я написав запит, dm_db_partition_statsщоб повідомити про різницю (після - перед) на сторінках:

Індекс 1 - це кластерний індекс, індекс 2 - первинний ключ. Інші некластеризовані та не унікальні.

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

Під час видалення чи повинен привид про перехід на іншу сторінку? Це має відношення до "унікалізаторів"?

Ми в середині розгортання RCSI, але зараз RCSI вимкнено.

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

Один з можливих сценаріїв, який дуже мене розважає:

• Рядки були написані спочатку, коли в базі даних не було ввімкнено зчитуваний знімок (RCSI), ізоляція знімків (SI) або групи доступності (AG)
• Увімкнено RCSI або SI або базу даних додано в групу доступності
• Під час видалення до видалених рядків додано 14-байтну часову позначку для підтримки зчитування RCSI / SI / AG

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

Щоб продемонструвати зростання, я взяв експорт бази даних Stack Overflow (у якому не ввімкнено RCSI) і створив купу індексів на таблиці повідомлень. Я перевірив розміри індексу за допомогою sp_BlitzIndex @Mode = 2 (скопіювати / вставити в електронну таблицю та трохи очистити, щоб максимально збільшити щільність інформації):

Потім я видалив приблизно половину рядків:

BEGIN TRAN;
DELETE dbo.Posts WHERE Id % 2 = 0;
GO

Приємно, поки делети траплялися, файл даних зростав і для розміщення часових міток! Звіт про використання диска SSMS показує події зростання - ось лише верх, щоб проілюструвати:

(Мені подобається демонстрація, де видалення роблять базу даних зростаючою.) Поки видалення працювало, я знову запустив sp_BlitzIndex. Зауважте, що кластерний індекс має менше рядків, але його розмір вже виріс приблизно на 1,5 Гб. Некластеризовані індекси на AcceptedAnswerId різко зросли - вони індексують за малим значенням, яке в основному є нульовим, тому їх розміри індексу майже вдвічі збільшилися!

Мені не потрібно чекати, коли видалення закінчиться, щоб довести це, тому я зупиню демонстрацію там. Справа в тому, що: коли ви робите великі вилучення на таблиці, яка була реалізована до того, як RCSI, SI або AG були включені, індекси (включаючи кластеризовані) можуть насправді зростати, щоб вмістити додавання часової мітки магазину версій.