Чому простір даних таблиці може займати в 4 рази більше розміру необроблених даних?

У мене є таблиця з 490 М рядками та 55 ГБ простору таблиці, тобто близько 167 байт у рядку. У таблиці є три стовпці: a VARCHAR(100), a DATETIME2(0)і a SMALLINT. Середня довжина тексту в VARCHARполі становить близько 21,5, тому необроблені дані повинні становити близько 32 байтів у рядку: 22 + 2 для числа VARCHAR, 6 для DATETIME2цілого і 2 для 16-бітного цілого числа.

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

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

Для порівняння я спробував створити таблицю з двома INTполями та 1 М рядками. Необхідний простір даних становив 16,4 Мб: 17 байт на рядок, порівняно з 8 байтами необроблених даних. Ще одна тестова таблиця з текстовим INTта VARCHAR(100)заповненим тим самим текстом, що і реальна таблиця, використовує 39 байт у рядку (44 К рядків), де я б очікував 28 плюс трохи.

Тож виробничий стіл має значно більше накладних витрат. Це тому, що вона більша? Я очікую, що розміри індексу будуть приблизно N * log (N), але я не бачу, чому простір, необхідний для фактичних даних, має бути нелінійним.

Заздалегідь дякую за будь-які покажчики!

Редагувати:

Усі перелічені поля є NOT NULL. Реальна таблиця має кластеризовану ПК на VARCHARполі та в DATETIME2полі, у такому порядку. Для двох тестів першим INTбув (кластерний) ПК.

Якщо це має значення: таблиця - це запис результатів ping. Поля - це URL-адреса, дата / час ping та затримка в мілісекундах. Дані постійно додаються та ніколи не оновлюються, але дані періодично видаляються, щоб зменшити їх до кількох записів на годину за URL.

Редагувати:

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

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

Завжди варто перевірити стан фрагментації за допомогою sys.dm_db_index_physical_stats в цих ситуаціях.

Редагувати: Після оновлення в коментарях

Середня щільність сторінки (до відновлення кластерного індексу) становила 24%, що ідеально відповідає початковому питанню. Сторінок було заповнено лише на 1/4, тож загальний розмір становив у 4 рази більше необробленого розміру даних.

Дискові структури мають накладні витрати:

• заголовок рядка
• null bitmap + pointer
• Зсуви стовпців змінної довжини
• вказівники на рядкові версії (необов’язково)
• ...

Беручи 2 x 4 байти int стовпців, у вас є

• Заголовок рядка 4 байти
• 2-байтний покажчик на NULL растрову карту
• 8 байт за 2 int стовпці
• 3 байти растрової карти NULL

Вау 17 байт!

Ви можете зробити те ж саме для своєї другої тестової таблиці, яка має більше накладних витрат, як ваша оригінальна:

• 2 байти для підрахунку стовпців змінної довжини
• 2 байти на стовпчик змінної довжини

Чому різниця? Крім того (я не буду посилатися на них)

• ви коли-небудь перебудовували індекси, щоб дефрагментувати їх?
• делети не повертають пробіл
• сторінки даних розділяться, якщо вставити їх в середину
• оновлення можуть спричинити покажчики вперед (залишає пробіл)
• рядок переповнення
• вилучений стовпчик varchar без відновлення індексу або DBCC CLEANTABLE
• купа або таблиця (у heap немає кластерного індексу = записи, розкидані по всьому)
• Рівень ізоляції RCSI (додаткові 14 байт у рядку)
• трейлінг пробілів (SET ANSI_PADDING за замовчуванням увімкнено) у varchar. Використовуйте DATALENGTH для checl, а не LEN
• Запустіть sp_spaceused з @updateusage = 'true'
• ...

Дивіться це: SQL Server: як створити таблицю, яка заповнює одну сторінку 8 Кб?

Від SO:

• /programming/4614771/sql-server-2008-how-much-space-does-this-occupy/4614799#4614799
• /programming/3793022/how-to-come-to-limits-of-8060-bytes-per-row-and-8000-per-varchar-nvarchar-valu/3793265#3793265

Чи змінилися типи даних з часом? Видалено стовпці змінної довжини? Чи часто дефрагментовані індекси, але ніколи не відбудовувалися? Видалено чимало рядків чи значно оновлено стовпчики змінної довжини? Деякий гарне обговорення тут .