Есть ли какая-то причина для производительности использовать в моей базе данных степени двойки для размеров полей?

Question

Давным-давно, когда я был молодым, я много занимался программированием на ассемблере и оптимизации. Сегодня я в основном занимаюсь созданием веб-приложений (это тоже нормально ...). Однако всякий раз, когда я создаю поля для таблиц базы данных, я использую такие значения, как 16, 32 и 128, для текстовых полей и пытаюсь объединить логические значения в поля данных SET.

Даст ли текстовое поле длину 9, что замедлит мою базу данных в долгосрочной перспективе, и я действительно помогу ей, указав длину поля, которая будет более легко выровнена по памяти?

Answer 1

Оптимизация базы данных совершенно не похожа на оптимизацию машинного кода. В случае баз данных большую часть времени вы хотите уменьшить дисковый ввод-вывод, а тщательная попытка выровнять поля приведет к тому, что меньше записей поместится в блок / страницу диска. Кроме того, если какое-либо выравнивание выгодно, ядро ​​базы данных сделает это автоматически.

Что будет иметь наибольшее значение, так это индексы и то, насколько хорошо вы их используете. Попытки уловить, чтобы упаковать больше информации в меньшем количестве места, могут легко усложнить получение хороших индексов. (Однако не переусердствуйте; не только индексы не только замедляют вставки и обновления до индексированных столбцов, но и требуют больше работы для планировщика, который должен учитывать все возможности.)

Большинство баз данных имеют команду EXPLAIN; попробуйте использовать его для выбора (в частности, для тех, у которых более одной таблицы), чтобы понять, как механизм базы данных будет работать.

Answer 2

Размер самого поля может быть важным, но обычно для текста, если вы используете nvarchar или varchar, это не имеет большого значения. Так как БД будет брать то, что вы используете. последующее будет иметь большее влияние на вашу скорость SQL:

не иметь больше столбцов, чем вам нужно. Большая таблица в терминах столбцов означает, что база данных с меньшей вероятностью найдет результаты ваших запросов на той же странице диска. Обратите внимание, что это верно, даже если вы запрашиваете только 2 из 10 столбцов в своем выборе ... (есть один способ бороться с этим, с кластеризованными индексами, но это может решить только один ограниченный сценарий).

Вы должны предоставить более подробную информацию о типе проблем / альтернатив дизайна, которые вы рассматриваете, чтобы получить дополнительные советы.

Answer 3

Нечто, что подразумевается выше, но которое может быть сделано явным. У вас нет никакого способа узнать, что на самом деле делает компьютер. Это не то время, когда вы могли смотреть на ассемблер и хорошо знать, какие шаги предпримет программа. Значение, которое «выглядит» так, как будто оно находится в регистре процессора, на самом деле, возможно, должно быть получено из кэша на чипе или даже с диска. Если вы пишете не на ассемблере, а используете оптимизирующий компилятор или, еще более точно, байт-код на движке (Java, C #), оставьте надежду. Или отказаться от беспокойства, что является лучшей идеей.

Вероятно, для написания или извлечения этого значения БД потребуются тысячи, а может быть, десятки тысяч машинных циклов. Не беспокойтесь о 10 дополнительных циклах из-за полного выравнивания слов.