Является ли поле BIT быстрее, чем поле int в SQL Server?

Question

У меня есть таблица с некоторыми полями, значение которой будет равно 0. Эти таблицы будут очень большими со временем. Хорошо ли использовать битовый тип данных или лучше использовать другой тип для производительности? Конечно, все поля должны быть проиндексированы.

Answer 1

Я не могу дать вам какую-либо статистику по производительности, однако вы всегда должны использовать тип, который лучше всего отражает ваши данные. Если все, что вам нужно, это 1-0, то вам абсолютно необходимо использовать битовое поле.

Чем больше информации вы можете предоставить вашей базе данных, тем больше вероятность, что она правильно "угадывает".

Answer 2

Официально бит будет самым быстрым, особенно если вы не разрешаете нули. На практике это может не иметь значения даже при широком использовании. Но если значение будет только 0 или 1, почему бы не использовать немного? Похоже, это лучший способ убедиться, что значение не будет заполнено недопустимыми данными, такими как 2 или -1.

Answer 3

Это зависит.

Если вы хотите максимизировать скорость выбора, используйте int (tinyint для экономии места), потому что бит в предложении where медленнее, чем int (не радикально, но каждая миллисекунда считается). Также сделайте столбец не нулевым, что также ускоряет процесс. Ниже приведена ссылка на реальный тест производительности, который я бы порекомендовал запустить в вашей собственной базе данных, а также расширить его, используя не нули, индексы и используя несколько столбцов одновременно. Дома я даже пытался сравнить, используя несколько битовых столбцов и несколько столбцов tinyint, а столбцы tinyint были быстрее (select count(*) where A=0 and B=0 and C=0). Я думал, что SQL Server (2014) оптимизирует, выполняя только одно сравнение с использованием битовой маски, поэтому он должен быть в три раза быстрее, но это не так. Если вы используете индексы, вам потребуется более 5000000 строк (как в тесте), чтобы заметить разницу (что у меня не хватило терпения, поскольку заполнение таблицы несколькими миллионами строк заняло бы много времени на моей машине).

https://www.mssqltips.com/sqlservertip/4137/sql-server-performance-test-for-bit-data-type-in-a-where-clause/

Если вы хотите сэкономить место, используйте бит, поскольку 8 из них могут занимать один байт, тогда как 8 крошечных будут занимать 8 байтов. Что составляет около 7 мегабайт на каждый миллион строк.

Различия между этими двумя случаями в основном пренебрежимо малы, и поскольку использование бита имеет преимущество в том, что столбец представляет просто флаг, я бы рекомендовал использовать бит.

Answer 4

Насколько я понимаю, вам все еще нужен байт для хранения битового столбца (но вы можете хранить 8-битные столбцы в одном байте). Таким образом, большое количество (сколько?) Этих битовых столбцов может немного сэкономить на хранении. Как сказал Ишай, производительность, скорее всего, не сильно повлияет на производительность (хотя в коде приложения будет немного больше логики).

Если вы можете со 100% уверенностью утверждать, что две опции для этого столбца НИКОГДА не изменятся, то непременно используйте бит. Но если вы увидите, что в будущем может появиться третье значение, это может немного облегчить жизнь, когда в этот день придет использование tinyint.

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