Зберігання SQL SERVER TinyInt


12

Чому в SQL Server зберігається крихітний файл з 9B у рядку. Чомусь здається, що в кінці растрової маски NULL є додатковий байт.

    USE tempdb;
    ПОВЕРНУТИСЯ

    СТВОРИТИ ТАБЛИЦЮ tbl
    (
        я TINYINT НЕ NULL
    );
    ПОВЕРНУТИСЯ

    ВСТУПИТИ В tbl (i)
        ЦІННОСТІ (1);
    ПОВЕРНУТИСЯ

    DBCC IND ('tempdb', 'tbl', - 1);
    ПОВЕРНУТИСЯ

    DBCC TRACEON (3604); - Дамп сторінки піде на консоль
    ПОВЕРНУТИСЯ

    DBCC PAGE ('tempdb', 1,168,3);
    ПОВЕРНУТИСЯ

Результати (я перевернув байти через DBCC PAGE, який показує найменш значущий байт):

Record Size = 9B
10000500 01010000 00
TagA = 0x10 = 1B
TagB = 0x00 = 1B
Null Bitmap Offset = 0x0005 = 2B
Our integer column = 0x01 = 1B
Column Count = 0x0001 = 2B
NULL Bitmap = 0x0000 = 2B (what!?)

1
Це просто навчально? Я все для того, щоб обрізати простір там, де потрібно, але це, мабуть, не 1 байт, про який я буду хвилюватися ...
Аарон Бертран

Це навчальний. Моя наступна розмова про SQLSaturday - на компресіні; Таким чином, я створив приклади для кожного типу даних, щоб допомогти людям зрозуміти наслідки їх вибору типу даних та показати вплив стиснення на всі типи даних.
ooutwire

Я припускав, що tinyint буде зберігатися як 1B (він є) із 7B накладних витрат. Цікаво, який додатковий байт знаходиться в кінці запису ???
Ooutwire

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

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

Відповіді:


12

Якщо ви обчислите запис за допомогою простого додавання розміру, ви дійсно отримаєте 8: 4 + 1 + 2 + 1 (заголовок + фіксований розмір + нульове число растрових зображень + нульовий растровий малюнок). Але запис купи не може бути меншим за розмір заглушки для переадресації , який становить 9 байт, оскільки запис повинен гарантувати, що його можна замінити заглушкою для переадресації. Отже, запис буде фактично на 9 байт. A smallintбуде 9 байтів як за допомогою обчислення, так і за розміром min. Все, що більше, вже більше заглушки для переадресації, тому ваш розмір обчислень відповідає рекордному розміру.


9 байт також застосовується до цього визначення, CREATE TABLE tbl (i TINYINT NOT NULL PRIMARY KEY)тому чи просто загальне правило для всіх рядків, чи є вони частиною купи?
Мартін Сміт

1
B-дерево може бути перетворене в купу ( alter table ... drop constraint), і операція не є повною перебудовою (верхні сторінки b-дерева відкидаються, сторінки листків залишаються від’єднаними, а результат - купа), тому логіка резервування все ще застосовується .
Рем Русану

Я думаю , що це доводить, що Рем заявив ... improve.dk/archive/2011/06/07 / ...
ooutwire

6

Приємно мати вухо автора. :-) Кален підозрює, що це лише виконання якоїсь мінімальної довжини рядка, де що-небудь <9 забито до 9. Звичайно, є лише кілька випадків, коли це можливо. Ви знайдете цей байт-фантом для TINYINT і BIT, а також VARCHAR (1) / CHAR (1). Він не збільшиться за 9, якщо ви перейдете до SMALLINT або CHAR (2), але збільшиться, якщо ви перейдете до, скажімо, CHAR (3).

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

EDIT Я сподіваюся мати більш конкретну інформацію для вас. Просто хотів повідомити, що саме так вважає автор книги "Інтернаси". Вона не на 100% впевнена.


Дякую Аарону за те, що він звернувся до Кален. Я копав цю книжку минулої ночі і витягав волосся. Це щось на кшталт додаткових байтів метаданих для sql_variant, за винятком того, що тут я не маю можливості пояснити збереження байта фантома для махання рукою та крику "Так це так!"
ooutwire

1
Що ж, ви можете зв'язати цей коментар із "це крайній крайній випадок, оскільки не багато таблиць ніколи не розроблені для того, щоб намагатися зберігати по одному крихітному чи символічному знаку (1) у кожному рядку".
Аарон Бертран
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.