Как varchar столбцы обрабатываются внутренне механизмом базы данных? Для столбца, определенного как символ (100), DBMS выделяет 100 непрерывных байтов на диске. Однако для столбца, определенного как varchar (100), который, по-видимому, не имеет место, так как, смысл varchar не должен больше выделять место, чем необходимый для хранения фактического значения данных, сохраненного в столбце. Так, когда пользователь обновляет строку базы данных, содержащую пустой varchar (100) столбец к значению, состоящему из 80 символов, например, где делает пространство для тех 80, символы выделяются от? Кажется, что varchar столбцы должны привести к изрядному количеству фрагментации фактических строк базы данных, по крайней мере, в сценариях, где значения столбцов первоначально вставляются как пробел или ПУСТОЙ УКАЗАТЕЛЬ, и затем обновляются позже с фактическими значениями. Эта фрагментация приводит к ухудшенной производительности на запросах базы данных, в противоположность использованию символьных значений типа, где место для столбцов, сохраненных в строках, выделено непрерывно? Очевидно, использование varchar приводит к меньшему дисковому пространству, чем использование символа, но является там хитом производительности при оптимизации для производительности запросов, специально для столбцов, значения которых часто обновляются после начальной вставки?
Структуры данных, используемые в ядре базы данных, намного сложнее, чем вы думаете! Да, есть проблемы фрагментации и проблемы, при которых обновление varchar с большим значением может привести к снижению производительности, однако трудно объяснить / понять, каковы последствия этих проблем, без более полного понимания задействованных структур данных.
Для Сервер MS Sql, возможно, вы захотите начать с понимания страниц - основной единицы хранения (см. http://msdn.microsoft.com/en-us/library/ms190969.aspx )
В терминах Из-за влияния исправлений на производительность и типов хранилища переменных на производительность необходимо учитывать ряд моментов:
В своем вопросе вы делаете много предположений, которые не обязательно верны.
Тип столбца a в любой СУБД вообще ничего не говорит вам о характере хранения эти данные, если в документации четко не указано, как они хранятся. ЕСЛИ это не указано, вы не знаете, как он хранится, и СУБД может свободно изменять механизм хранения от выпуска к выпуску.
Фактически, некоторые базы данных хранят поля CHAR внутри как VARCHAR, в то время как другие принимают решение о том, как сохранить столбец на основе заявленного размера столбца. Некоторые базы данных хранят VARCHAR с другими столбцами, некоторые с данными BLOB, а некоторые реализуют другое хранилище. Некоторые базы данных всегда перезаписывают всю строку при обновлении столбца, другие - нет. Некоторые заполняют VARCHAR, чтобы обеспечить ограниченное обновление в будущем без перемещения хранилища.
СУБД отвечает за выяснение того, как хранить данные и возвращать их вам быстро и согласованно. Меня всегда удивляет, сколько людей пробуют использовать базу данных, как правило, до обнаружения каких-либо проблем с производительностью.
В SQL Server varchar (за исключением varchar (MAX)) обычно хранится вместе с остальными данными строки (на той же странице, если данные строки <8 КБ, и в том же экстенте, если это <64 КБ. Только большие типы данных, такие как TEXT, NTEXT, IMAGE, VARHCAR (MAX), NVARHCAR (MAX), XML и VARBINARY (MAX), хранятся отдельно.
Ответ будет зависеть от конкретной СУБД. Для Oracle, безусловно, можно получить фрагментацию в виде «связанных строк», что приведет к снижению производительности. Однако вы можете смягчить это, предварительно выделив некоторое пустое пространство в блоках таблицы, чтобы обеспечить некоторое расширение из-за обновлений. Однако столбцы CHAR обычно делают таблицу намного больше, что имеет собственное влияние на производительность.
Это будет полностью зависеть от базы данных.
Я знаю, что в Oracle база данных резервирует определенный процент каждого блока для будущих обновлений (параметр PCTFREE). Например, если для PCTFREE установлено значение 25%, то блок будет использоваться только для новых данных, пока он не будет заполнен на 75%. Таким образом, остается место для роста рядов. Если строка растет так, что 25% зарезервированного пространства полностью израсходованы, то в конечном итоге вы получаете цепочки строк и снижение производительности. Если вы обнаружите, что таблица имеет большое количество связанных строк, вы можете настроить PCTFREE для этой таблицы. Если у вас есть таблица, в которой вообще никогда не будет обновлений, значение PCTFREE, равное нулю, будет иметь смысл
Ваш вопрос слишком общий, потому что разные механизмы баз данных будут вести себя по-разному. Если вам действительно нужно это знать, я предлагаю вам настроить тест, чтобы записать большое количество записей и рассчитать время. Вам нужно, чтобы на запись у вас ушел не менее часа.
Как вы предложили, было бы интересно посмотреть, что произойдет, если вы напишете вставить все записи с пустой строкой (""), а затем обновите их, чтобы 100 символов, которые являются достаточно случайными, а не просто 100 X.
Если вы попробуете это с SQLITE и не увидите существенной разницы, то я думаю, маловероятно, что более крупные серверы баз данных со всем анализом и настройкой, которые проводятся, будут хуже, чем SQLITE.