В чем улучшение производительности базы данных при хранении в виде чисел, а не текста?

Question

Предположим, у меня есть текст, такой как "Win", "Lose", "Incomplete", "Forfeit" и т. Д. Я могу напрямую сохранить текст в базе данных.Вместо этого, если использовать такие числа, как 0 = выигрыш, 1 = проигрыш и т. Д., Получу ли я существенное улучшение производительности базы данных?В частности, для запросов, где поле является частью моего предложения WHERE

Answer 1

На уровне ЦП сравнение двух целых чисел фиксированного размера занимает всего одну инструкцию, тогда как сравнение строк переменной длины обычно включает циклический просмотр каждого символа.Таким образом, для очень большого набора данных должно быть значительное повышение производительности при использовании целых чисел.

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

Однако большинство систем баз данных имеют тип enum, который предназначен для таких случаев, как ваш, - в запросе вы можете сравнить значение поля с фиксированным набором литералов, пока оно внутренне хранится как целое число.

Answer 2

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

При этом почти наверняка никогда не будет хуже использовать число для представления перечислимого типа.

Answer 3

Может быть значительное повышение производительности, если столбец используется в индексе.

Answer 4

Не угадай. Измерить.

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

Когда я проектировал базу данных для хранилища оперативных данных моего работодателя, я построил испытательный стенд с таблицами, созданными на основе естественных ключей, и таблицами, созданными на основе числовых идентификаторов. Обе эти схемы содержат более 13 миллионов строк компьютерных образцов данных. В некоторых случаях запросы к схеме идентификатора превосходили схему естественного ключа на 50%. (Таким образом, сложный запрос, который занимал 20 секунд с номерами идентификаторов, занимал 30 секунд с естественными ключами.) Но 80% тестовых запросов имели более высокую производительность SELECT по сравнению со схемой естественного ключа. И иногда это было потрясающе быстрее - разница от 30 до 1.

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

Answer 5

наличие столбца обложки означает, что вы можете разместить больше строк на странице.

это ОГРОМНАЯ разница между varchar (20) и целым числом.

Answer 6

Очевидно, что если ваши структуры данных короче, они быстрее сравниваются и быстрее сохраняются и извлекаются.

Насколько быстрее 1, 2, 1000. Все зависит от размера таблицы и т. Д..

Например: скажем, у вас есть таблица с productId и текстовым столбцом varchar.

Каждая строка будет занимать примерно 4 байта для int, а затем еще 3-> 24 байта для текста в вашем примере (в зависимости от того, является ли столбец обнуляемым или имеет Unicode)

Сравните это с 5 байтами в строке для тех же данных со столбцом состояния byte.

Эта огромная экономия пространства означает, что на страницу помещается больше строк, больше данных помещается в кэш, меньше записей происходит при загрузке данных хранилища и т. Д.

Кроме того, сравнение строк в лучшем случае выполняется так же быстро, как сравнение байтов, а в худшем случае - намного медленнее.

Существует вторая огромная проблема с хранением текста, в которой вы намеревались получить перечисление.Что происходит, когда люди начинают хранить Incompete, а не Incomplete?