Mysql: влияет ли размер поля/ширина экрана на производительность индекса?

Question

CREATE TABLE student(
`id` int(11) auto_increment PRIMARY KEY 
`grade` int(11) 
) 

Предположим, я хочу добавить индекс на столбец grade. Имеет ли значение значение, если оно имеет меньшую ширину отображения, например, int(4)?

EDIT:

• По performance здесь я имею в виду время запроса.

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

Answer 1

Во-первых, отображение не имеет значения в любом случае - это просто то, как поле будет представлено в ответах на запросы. int еще и int с помощью 4 байтов, bigint является bigint использованием 8bytes и т.д ...

С какой аспект вы рассматриваете 'производительность? Общее время запроса, использование памяти, необходимое для хранения или кэширования данных и индексов? Дисковое пространство?

Я предполагаю, что вы имеете в виду, повлияет ли он на то, как быстро ответ отвечает.

Этот вопрос, однако, довольно широк, реальный ответ - это зависит. Ваша система 64 или 32 бит? Сколько записей мы говорим? Является ли поле частью гораздо более сложного составного индекса, но все еще его небольшой частью?

(ПРИМЕЧАНИЕ: необходимо проверить эту претензию, например, если CHARs просто хешированы для индексов). Перейдите от CHAR (4) к CHAR (32) и убедитесь, что вы можете найти какой-то незначительный удар производительности, но это связано не со сложностью, а с дополнительными накладными расходами на вашу ОС и архитектуру.

Однако я собираюсь выйти на конечность и предложить, запретив изменение типов (int to varchar), которые могут изменить метод индексирования или массивное изменение размера хранилища вашего индекса, вы, вероятно, не будете «видеть» любую разницу. Я сомневаюсь, что между разными целыми типами вы сможете легко показать последовательное замедление.

Answer 2

Короткий ответ: (4) ничего не значит для INT.

ответ займет слишком много:

Колонка размеры влияние на размер строк, который влияет на размер таблицы, который влияет на скорость запросов. Но ...

Если таблица «маленькая», разница в производительности будет очень небольшой.

Если таблица больше, чем может быть кэширована в ОЗУ, то разница может быть значительной - потому что вы, вероятно, будете связаны с I/O. В некоторых ситуациях это десятикратное замедление.

Для того, чтобы сжать в INT, который является 4 байта всегда, переключиться на TINYINT UNSIGNED (1 байт, диапазон: 0..255), SMALLINT UNSIGNED (2 байта, 0..65K), или MEDIUMINT UNSIGNED (3 байта , 0,16М).

Предполагая, что grade - 0..100, тогда TINYINT (подписанный или неподписанный) является оптимальным.

Между тем, вы можете изменить свое изменение id.

единственной целью из INT(4) в сочетании с ZEROFILL, где вы хотите, чтобы отобразить 12, как 0012. Это очень редко.

Не используйте CHAR, если строки действительно не являются Фиксированная длина строк. И тогда он, вероятно, должен быть явно объявлен CHARACTER SET ascii, потому что это шестнадцатеричный, все цифры или двухбуквенный country_code (и т. Д.). Во всяком случае, utf8 переполнен.

Предполагая, что вы используете InnoDB, то «вторичный» INDEX(grade) неявно включают PRIMARY KEY(id). Таким образом, размер каждой записи индекса - это размер grade плюс размер id плюс куча накладных расходов. Предполагая, что нормальные классы и не более 65 тыс. Студентов, вы можете использовать 3 байта вместо оригинала 8. Но таблица небольшая, поэтому вы вряд ли будете связаны с I/O-привязкой. Следовательно, небольшие накладные расходы для 8 вместо 3.