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

Question

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

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

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

и

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

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

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

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

[Изменить]

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

Answer 1

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

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

Answer 2

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

Answer 3

Есть еще какие-нибудь ошибки?

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

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

Answer 4

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

Answer 5

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