Я собираюсь создать таблицу, и это заставило меня задуматься.
Если я буду хранить, скажем, автомобили, у которых есть марка (fx BMW, Audi ect.), будет ли разница в скорости запроса, если я буду хранить make как int или varchar.
Итак,
SELECT * FROM table WHERE make = 5 AND ...;
Быстрее/медленнее, чем
SELECT * FROM table WHERE make = 'audi' AND ...;
или скорость будет более или менее одинаковой?
Сравнение Int быстрее, чем сравнение с varchar, поскольку тот факт, что ints занимает гораздо меньше места, чем varchars.
Это справедливо как для неиндексированного, так и для индексированного доступа. Самый быстрый способ - индексированный столбец int.
Как я вижу, вы отметили вопрос postgreql, вы можете быть заинтересованы в использовании пространства разных типов дат:
int поля занимают между 2 и 8 байтами, причем 4 обычно более чем достаточно (-2147483648 до +2147483647)Некоторые приблизительные ориентиры:
4 миллиона записей в Postgres 9.x
Table A = base table with some columns
Table B = Table A + extra column id of type bigint with random numbers
Table C = Table A + extra column id of type text with random 16-char ASCII strings
Результаты на 8 ГБ оперативной памяти, i7, ноутбук SSD:
Size on disk: A=261MB B=292MB C=322MB
Non-indexed by id: select count(*), select by id: 450ms same on all tables
Insert* one row per TX: B=9ms/record C=9ms/record
Bulk insert* in single TX: B=140usec/record C=180usec/record
Indexed by id, select by id: B=about 200us C=about 200us
* inserts to the table already containing 4M records
чтобы он выглядел как эта настройка, если ваши индексы соответствуют ОЗУ, текст bigint vs 16- char не влияет на скорость.
Это будет немного быстрее, используя int вместо varchar. Более важным для скорости является наличие индекса в поле, которое запрос может использовать для поиска записей.
Существует еще одна причина использования int, а именно нормализация базы данных. Вместо того, чтобы в таблице хранился текст "Мерседес-Бенц" тысячи раз, вы должны сохранить его идентификатор и сохранить имя бренда в отдельной таблице.
Переход к фактической производительности сопоставления строк по сравнению с неплавками, в этом случае любой размер без знака и подпись не имеет значения. Фактически размер фактической разницы в производительности. Будь то 1 байт + (до 126 байт) по сравнению с 1,2,4 или 8 байтами сравнения... очевидно, что не-float меньше строк и поплавков и, следовательно, больше совместим с процессором в сборке.
Сравнение строк со строками во всех языках медленнее, чем то, что можно сравнить в 1 команде CPU. Даже сравнение 8 байтов (64 бит) на 32-битном процессоре все еще быстрее, чем VARCHAR (2) или больше. * Опять же, посмотрите на произведенную сборку (даже вручную), для сравнения char на char требуется больше инструкций, чем число от 1 до 8 байтов ЦП.
Теперь, насколько быстрее? зависит также от объема данных. Если вы просто сравниваете 5 с "audi" - и это все, что есть у вашей БД, получившаяся разница настолько минимальна, что вы никогда ее не увидите. В зависимости от процессора, реализации (клиент/сервер, web/ script и т.д.) Вы, вероятно, не увидите его, пока не нажмете несколько сотен сравнений на сервере БД (возможно, даже пару тысяч сравнений, прежде чем это станет заметно).
Ozz
В общем случае int будет быстрее. Чем длиннее varchar, тем медленнее он получает
Индекс или нет, int намного быстрее (чем длиннее varchar, тем медленнее он становится).
Другая причина: индекс в поле varchar будет намного больше, чем на int. Для больших таблиц это может означать сотни мегабайт (и тысячи страниц). Это значительно ухудшает производительность, поскольку чтение индекса просто требует большого количества чтения на диске.
Подсказка. Если возможные значения для поля make будут никогда (или редко) изменяться, вы можете использовать ENUM в качестве компромисса. Он сочетает в себе хорошую скорость и хорошую читаемость.
Если вы включите индексирование в любом из полей, это будет быстрее. Что касается вашего вопроса, я думаю, что int быстрее, чем varchar.
Несколько относительный. Да, INTs будет быстрее, но вопрос в том, заметен ли он в вашей ситуации. Являются ли VARCHAR просто небольшими словами или более длинными текстами? и сколько строк в таблице? Если есть всего несколько строк, он, скорее всего, будет полностью забуферирован в памяти (при частом запросе), в этом случае вы не заметите большой разницы. Тогда, конечно, есть индексирование, которое становится более важным, когда таблица растет. Использование SSD может быть быстрее, чем HD с оптимизированными запросами. Также хорошие дисковые контроллеры иногда ускоряют запросы > 10x. Это может оставить место для использования VARCHAR, что упрощает чтение и запись запросов (не нужно писать сложные объединения) и ускорить разработку. Пуристы, однако, не согласятся и всегда нормализуют все.