Является ли varchar (128) лучше, чем varchar (100)
быстрый вопрос. Имеет ли значение с точки зрения хранения данных, буду ли я использовать десятичные ограничения поля или шестнадцатеричные (скажем, 16,32,64 вместо 10,20,50)?
Я спрашиваю, потому что мне интересно, будет ли это иметь какое-либо отношение к кластерам на HDD?
спасибо!
3 ответов
VARCHAR (128) лучше, чем VARCHAR(100), если вам нужно хранить строки длиной более 100 байт.
в противном случае между ними очень мало выбора; вы должны выбрать тот, который лучше соответствует максимальной длине данных, которые вам могут понадобиться для хранения. Вы не сможете измерить разницу в производительности между ними. Кроме того, СУБД, вероятно, хранит только отправленные вами данные, поэтому, если ваша средняя строка составляет, скажем, 16 байт, она будет использовать только 16 (или, скорее, 17 - разрешение 1 байт для хранения длины) байт на диске. Больший размер может повлиять на вычисление того, сколько строк может поместиться на странице - отрицательно. Поэтому выбирать наименьший размер, адекватный имеет смысл-не тратить, не хотеть.
таким образом, в целом, существует очень мало разницы между ними с точки зрения производительности или использования диска, и выравнивание по удобным бинарным границам на самом деле не имеет значения.
Если бы это была C-программа, Я бы тоже потратил некоторое время, чтобы подумать об этом. Но с базой данных я бы оставил ее движку DB.
программисты DB потратили много времени на размышления о лучшей компоновке памяти, поэтому просто скажите базе данных, что вам нужно, и она будет хранить данные таким образом, который лучше всего подходит для DB engine (обычно).
если вы хотите выровнять свои данные, вам понадобится точно знание внутренней организации данных: как строка сохранена? Один, два или 4 байта для хранения длины? Он хранится как простая последовательность байтов или закодирован в UTF-8 UTF-16 UTF-32? Нужны ли БД дополнительные байты для идентификации значений NULL или > MAXINT? Возможно, строка хранится как последовательность байтов с нулевым завершением-тогда внутри требуется еще один байт.
также с VARCHAR не обязательно верно, что DB всегда будет выделять 100 (128) байтов для вашей строки. Возможно, он хранит только указатель на то, где пространство для фактических данных есть.
поэтому я настоятельно рекомендую использовать VARCHAR (100), если это ваше требование. Если БД решит как-то выровнять его, есть место и для дополнительных внутренних данных.
другой способ: предположим, вы используете VARCHAR (128), и все вещи объединяются: DB выделяет 128 байтов для ваших данных. Кроме того, ему нужно еще 2 байта для хранения фактической длины строки - составляет 130 байт - и тогда может быть, что DB выравнивает данные до следующей (скажем, 32 байта) границы: Фактические данные, необходимые на диске, теперь составляют 160 байт 8 -}
да, но это не так просто. Иногда 128 может быть лучше 100, а иногда наоборот.
так что же происходит? varchar только выделяет пространство по мере необходимости, поэтому, если вы храните hello world на varchar(100) это займет ровно столько же места, сколько и в varchar(128).
вопрос: если вы заполните строки, вы нажмете" блок " предел / граница или нет?
базы данных хранят свои данные в блоках. Они имеют фиксированный размер, для пример 512 (это значение можно настроить для некоторых баз данных). Итак, вопрос: сколько блоков нужно прочитать БД, чтобы получить каждую строку? Строки, которые охватывают несколько блоков, потребуют больше ввода-вывода, поэтому это замедлит вас.
но опять же: это не зависит от теоретического максимального размера столбцов, а от a) сколько столбцов у вас есть (каждый столбец требует немного места, даже если он пуст или null), b) сколько столбцов фиксированной ширины у вас есть (number/decimal, char), и, наконец, c) сколько данных у вас есть в переменных столбцах.