Коли використовувати TINYINT над INT?

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

Наприклад, краще використовувати, tinyintколи ви знаєте, що єдині дані, які ви будете зберігати, - це 1, 0 або нуль (з дуже малим шансом розширити їх на 2 або 3 пізніше).

Однак єдина причина, яку я знаю для цього - це для зберігання даних - використання 1 байта в рядку замість 4 байтів.

Які наслідки використання tinyint(або smallintнавіть навіть bigint) просто int, крім економії місця на жорсткому диску?

Місце на диску дешево ... в цьому справа не в цьому!

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

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

Мені нагадали про оточення, описане в попередньому запитанні . 400+ баз даних, розміром від 50 Мб до 50 ГБ, на екземпляр SQL. Вичищення декількох байт на запис, на таблицю, на базу даних у цьому середовищі може суттєво змінитись.

Окрім інших відповідей ...

Рядки та записи індексів зберігаються на 8-ти сторінках. Таким чином, мільйон рядків по 3 байти в рядку не має 3 МБ на диску: це впливає на кількість рядків на сторінці ("щільність сторінки").

Це ж стосується і nvarchar до varchar, smalldatetime to datetime, int to tinyint тощо

Редагувати, червень 2013 року

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

У цій статті зазначено

Важливими критеріями є кардинальність та співвідношення сторінки до рядків.

Отже, вибір типу даних має значення

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

Я, безумовно, сподіваюся виявити, що вивчення записів індексу на сторінках BTREE буде трохи швидше при менших типах даних. Однак будь-які VARCHAR, що беруть участь у записах індексів, компенсують (анулюють) приріст продуктивності від використання TINYINT над INT.

Незважаючи на те, що якщо записи в індексі мають складені записи, і всі цілі числа, то менші цілі числа є побіжно, тим краще і швидше.

Усі речі набувають складності, коли бази даних збільшуються:

• вікна технічного обслуговування потрібно збільшити або перенести
• резервні копії (повна резервна копія в кінці дня стає абсурдною їжею часу, тому вам потрібні диференційні або навіть резервні копії та виконувати повний раз на тиждень, можливо, раз на місяць)
• Виконання вистав стає перебігом часу (створення індексу в багатомільйонній таблиці займає не тривіальний час для виконання) і його потрібно перенести і погіршити, якщо таблиця широка ...
• І передавання того, що резервне копіювання 100Gb через мережу - це не те, що я називаю шматок пирога - особливо якщо мережа (з незрозумілої причини) вперта на перерву підключення на позначці 75Gb ... (сталося з установкою, над якою я працював, робив резервну копію на картографічному диску в мережі - мережі) ...

І які типи даних пов’язані з цим? ВСЕ. Використання розмірів рядків, більших за необхідне, призводить до заповнення сторінок бази даних раніше, ніж потрібно, або навіть витрачання місця, якщо розмір рядка такий, що на сторінці не може бути записано не більше одного запису. Результат - більше сторінок, необхідних для написання та читання, більше пам’яті оперативної пам’яті використовується для кешування, що (для великих записів потрібна більша пам’ять). А оскільки ваші типи даних вказані більше, ніж потрібно на диску, ваші індекси зазнають тієї ж проблеми - особливо, якщо ви кластеризуєте цей первинний ключ з 2 BIGINT стовпців, оскільки будь-які інші створені індекси копіюють цей первинний ключ неявно під їх визначення.

Якщо ви знаєте, що в деяких стовпцях таблиці, що міститимуть мільйони рядків або навіть маленьку таблицю, буде FK'ed багатомільйонний ряд, якому не потрібно 4-байтне ціле число для зберігання своїх даних, але 2-байт буде достатньо - використовуйте SMALLINT . Якщо значень в діапазоні 0-255 достатньо, TINYINT . Прапор так / ні? Є БІТ .

Хоча для tinyintvs intіснують чіткі відмінності, такі як дисковий простір, розбиття сторінок та час обслуговування, для них не було б нічого varchar.

То чому б не оголосити всі текстові поля як varchar(4000), оскільки це все одно буде використовувати лише необхідний простір? Ще більше вам буде гарантовано, що ваші дані ніколи не будуть врізані.

Відповідь звичайно:

1. Уточнення своїх намірів (оскільки ніхто не зрозуміє, чому в полі імені має бути 4000 символів)
2. Перевірка, як ви хочете, щоб ніхто не вводив всю біографію як ім'я.

Ці самі причини стосуються tinyintі цього.