Скорость SQL SELECT int vs varchar - PullRequest
Новая
       22

Скорость SQL SELECT int vs varchar

94 голосов
/ 27 февраля 2010

Я нахожусь в процессе создания таблицы, и это заставило меня задуматься.

Если я сохраню, скажем, автомобили с маркой (например, BMW, Audi и т. Д.), Будет ли иметь какое-либо значение скорость выполнения запроса, если я сохраню марку как int или varchar.

Так же, как и 

SELECT * FROM table WHERE make = 5 AND ...;

Быстрее / медленнее 

SELECT * FROM table WHERE make = 'audi' AND ...;

или скорость будет более или менее одинаковой?

Ответы [ 9 ]

90 голосов
/ 27 февраля 2010

Сравнения Int быстрее, чем сравнения varchar, потому что тот занимает гораздо меньше места, чем varchars.

Это верно как для неиндексированного, так и для индексированного доступа. Самый быстрый способ - это индексированный столбец int.

Как я вижу, вы пометили вопрос postgreql, вас может заинтересовать использование места различными типами дат:

26 голосов
/ 23 сентября 2016

Некоторые приблизительные показатели:

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

Результаты на 8GB RAM, 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 не имеет значения по скорости.

18 голосов
/ 27 февраля 2010

Будет немного быстрее использовать int вместо varchar. Для скорости важнее иметь индекс в поле, которое запрос может использовать для поиска записей.

Есть еще одна причина использовать int, это нормализовать базу данных. Вместо того, чтобы текст «Mercedes-Benz» хранился тысячи раз в таблице, вам следует сохранить его идентификатор и один раз сохранить название бренда в отдельной таблице.

8 голосов
/ 03 марта 2016

Разбивка до фактической производительности сравнения строк по сравнению с не плавающими, в этом случае любой размер без знака и со знаком не имеет значения. Размер на самом деле истинная разница в производительности. Будь то 1 байт + (до 126 байт) по сравнению с 1,2,4 или 8-байтовым сравнением ... очевидно, что non-float меньше строк и float и, следовательно, более дружественен к процессору при сборке.

Сравнение строк со строками на всех языках медленнее, чем то, что может быть сравнено в одной инструкции ЦПУ. Даже сравнение 8-байтового (64-битного) на 32-битном процессоре все же быстрее, чем VARCHAR (2) или больше. * Опять же, посмотрите на произведенную сборку (даже вручную), для сравнения char с char требуется больше инструкций, чем от 1 до 8 байтов числового процессора.

Теперь, насколько быстрее? зависит также от объема данных. Если вы просто сравниваете 5 с 'audi' - и это все, что имеет ваша БД, то полученная разница настолько минимальна, что вы ее никогда не увидите. В зависимости от процессора, реализации (клиент / сервер, веб / скрипт и т. Д.) Вы, вероятно, не увидите его, пока не выполните несколько сотен сравнений на сервере БД (возможно, даже пару тысяч сравнений, прежде чем это станет заметно).

  • Чтобы избежать некорректного спора о сравнениях хешей. Сами большинство алгоритмов хеширования работают медленно, поэтому вам не нужны такие вещи, как CRC64 и менее. Более 12 лет я разрабатывал алгоритмы поиска для многострановых поисковых систем и 7 лет для кредитных бюро. Все, что вы можете хранить в цифрах, тем быстрее ... например, номера телефонов, почтовые индексы, даже валюта * 1000 (хранилище). Div валюты 1000 (поиск) быстрее, чем DECIMAL для сравнения.

Озз

6 голосов
/ 27 февраля 2010

Индексировать или нет, int намного быстрее (чем длиннее varchar, тем медленнее он становится).

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

4 голосов
/ 27 февраля 2010

В общем случае int будет быстрее. Чем дольше varchar, тем медленнее он становится

3 голосов
/ 27 февраля 2010

Совет: если возможные значения для поля make не будут никогда (или редко), вы можете использовать ENUM в качестве компромисса. Он сочетает в себе хорошую скорость и хорошую читаемость.

1 голос
/ 27 февраля 2010

Если вы включите , индексируя в любом из полей, это будет быстрее. Что касается вашего вопроса, я думаю, int быстрее, чем varchar.

0 голосов
/ 29 марта 2016

Относительно относительный. Да, INT будет быстрее, но вопрос в том, заметен ли он в вашей ситуации. VARCHAR - это просто маленькие слова или длинные тексты? а сколько строк в таблице? Если строк всего несколько, то, скорее всего, они будут полностью буферизованы в памяти (при частом запросе), в этом случае вы не заметите большой разницы. Затем, конечно, есть индексация, которая становится более важной, когда таблица растет. Использование SSD может быть быстрее, чем HD с оптимизированными запросами. Также хорошие контроллеры диска иногда ускоряют запросы> 10x. Это может оставить место для простого использования VARCHAR, что упрощает чтение и написание запросов (не нужно писать сложные объединения) и ускоряет разработку. Однако пуристы не согласятся и всегда все нормализуют.

...