Стоит ли использовать tinyint вместо int для таблиц поиска SqlServer?

При разработке таблицы поиска (enum) в SqlServer 2005, если вы знаете, что количество записей никогда не будет очень высоким, следует ли использовать tinyint вместо int? Меня больше всего беспокоит производительность, особенно эффективность индексов.

Скажем, у вас есть эти репрезентативные таблицы:

Person
------
PersonId int  (PK)
PersonTypeId tinyint  (FK to PersonTypes)

PersonTypes
-----------
PersonTypeId tinyint
PersonTypeName varchar(50)

Очевидными факторами являются размер данных и сложность кодирования. Когда мы получаем 100 миллионов строк в таблице человек, мы сохраняем 300 миллионов меньше байтов с tinyint, а не int, плюс пространство, занятое нашими индексами. Не огромный объем данных, но значительный, если проектное решение применяется к десяткам больших таблиц. Конечно, проблема с кодированием исходит из всех этих проблем с литьем в коде ASP.NET С#/VB.

Если мы отложим эти два вопроса, что еще входит в игру? Будет ли запрос намного более эффективным из-за уменьшения размера страниц индекса? Или есть какие-то дополнения, которые случаются, которые просто отрицают преимущества? Любые другие ошибки?

Я всегда просто использовал ints лично, но я рассматриваю tinyint для предстоящего процесса редизайна/миграции на некоторых огромных таблицах, поэтому я хотел бы получить совет.

[изменить]

После того, как вы экспериментировали с этим, проблемы с кодированием, которые я ожидал, оказались нецелевыми. Переход от int к tinyint не привел к какому-либо кастингу.

Ответ 1

Чем более узкая таблица (или индекс node), тем больше записей (или узлы индекса) могут помещаться на одну страницу ввода-вывода, а меньшее количество физических (и логических) операций чтения IO требуется для любого запроса. Кроме того, чем больше узлов индекса находится на одной странице, тем меньше уровней, которые могут быть в индексе, от уровня корня до листа, и если, делая таблицу более узкой, вы передаете порог, где индекс может быть на один уровень меньше, это может иметь драматический эффект на perforamnce.

Если, переключившись на TinyInt, вы измените таблицу шириной от 200 до 197 байт, она, вероятно, не будет иметь никакого значения... Но если вы измените ее с 20 до 14, (скажем, у вас есть 2 ints в там), то это может быть драматичным...

Ответ 2

Память 101: Меньший материал означает одновременное хранение в ОЗУ и, следовательно, меньшее количество жестких дисков. Если БД достаточно велик, и вы выполняете определенные запросы, это может быть очень серьезным фактором. Но это, вероятно, не будет иметь большого значения.

Ответ 3

Любые другие ошибки?

Я не уверен, что это то, о чем вы говорите, но я столкнулся с ситуациями, когда использование datetime вместо smalldatetime давало неправильное функциональное поведение, поскольку меньшее smalldatetime-значение не сравнивалось с эквивалент более высокой точности даты и времени для двух дат, которые в противном случае были "одинаковыми".

Здесь нет никаких шансов, так как tinyint/smallint/int/bigint будут сравниваться как одинаковые для одного и того же числового целочисленного значения. Таким образом, вы, очевидно, уверены в этом, не то, чтобы он точно ответил на ваш вопрос.

Ответ 4

Я сомневаюсь, что использование smallint вместо int будет иметь большую производительность, за исключением случаев с редким краем. Вы можете легко создать тестовое приложение для этого, создайте несколько тестовых таблиц и сделайте миллион вставок/обновлений/выбора и сравните производительность.

Ответ 5

Существует также фактор поддержания индексов/резервных копий на диске/резервных копий на магнитной ленте, которые также занимают место, но я бы сказал, что наиболее важным является производительность ввода-вывода и памяти.