Блог

Быстрый вопрос. Имеет ли значение с точки зрения хранения данных, буду ли я использовать десятичные ограничения полей или шестнадцатеричные (скажем, 16,32,64 вместо 10,20,50)?

Я спрашиваю, потому что мне интересно, будет ли это иметь какое-либо отношение к кластерам на жестком диске?

Спасибо!

VARCHAR(128) лучше, чем VARCHAR(100), если вам нужно хранить строки длиной более 100 байт.

В противном случае выбор между ними невелик; вы должны выбрать тот, который лучше соответствует максимальной длине данных, которые вам могут понадобиться для хранения. Вы не сможете измерить разницу в производительности между ними. Помимо всего прочего, СУБД, вероятно, хранит только данные, которые вы отправляете, поэтому, если ваша средняя строка составляет, скажем, 16 байт, она будет использовать только 16 (или, что более вероятно, 17, позволяя 1 байт для хранения длины) байт на диске. Больший размер может повлиять на вычисление того, сколько строк может поместиться на странице — в ущерб. Поэтому выбор наименьшего размера, который является адекватным, имеет смысл — не тратьте, не хотите.

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

Если бы это была C-программа, я бы тоже потратил некоторое время на размышления об этом. Но с базой данных я бы оставил это на усмотрение DB engine.

Программисты БД потратили много времени на обдумывание наилучшего расположения памяти, поэтому просто сообщите базе данных, что вам нужно, и она сохранит данные таким образом, который лучше всего подходит движку БД (обычно).

Если вы хотите выровнять свои данные, вам потребуется точное знание внутренней организации данных: как хранится строка? Один, два или 4 байта для хранения длины? Хранится ли он в виде простой последовательности байтов или закодирован в UTF-8 UTF-16 UTF-32? Нужны ли БД дополнительные байты для определения значений NULL или> MAXINT? Возможно, строка хранится в виде байтовой последовательности с нулевым завершением — тогда внутри требуется на один байт больше.

Также с VARCHAR необязательно верно, что БД всегда будет выделять 100 (128) байт для вашей строки. Возможно, он хранит только указатель на то, где находится место для фактических данных.

Поэтому я настоятельно рекомендую использовать VARCHAR(100), если это ваше требование. Если БД решит каким-то образом выровнять его, также останется место для дополнительных внутренних данных.

Наоборот: предположим, вы используете VARCHAR(128), и все вещи собираются вместе: БД выделяет 128 байт для ваших данных. Кроме того, для хранения фактической длины строки требуется на 2 байта больше — составляет 130 байт — и тогда может случиться так, что БД выровняет данные по следующей (скажем, 32-байтовой) границе: фактические данные, необходимые на диске, теперь составляют 160 байт 8-}

Да, но это не так просто. Иногда 128 может быть лучше, чем 100, а иногда наоборот.

Так что же происходит? varchar выделяет пространство только по мере необходимости, поэтому, если вы храните hello world в a varchar(100) , оно займет ровно столько же места, сколько и в a varchar(128) .

Вопрос в том, если вы заполните строки, достигнете ли вы предела / границы «блока» или нет?

Базы данных хранят свои данные в блоках. Они имеют фиксированный размер, например 512 (это значение может быть настроено для некоторых баз данных). Итак, вопрос в том, сколько блоков должна прочитать БД для извлечения каждой строки? Строкам, занимающим несколько блоков, потребуется больше операций ввода-вывода, так что это замедлит работу.

Но опять же: это зависит не от теоретического максимального размера столбцов, а от а) сколько у вас столбцов (для каждого столбца требуется немного места, даже если он пустой или null ), б) сколько у вас столбцов фиксированной ширины ( number / decimal , char ) и, наконец, в) каку вас много данных в переменных столбцах.