Сравнение MySQL varchar и IBM DB2 varchar dataype

У меня есть небольшое сомнение относительно типа данных MySQL varchar. Как мы все знаем.

char — это тип данных фиксированной длины. Таким образом, размер хранения значения char равен максимальному размеру столбца. Но в случае «varchar» это тип данных переменной длины, поэтому размер хранилища значения varchar — это фактическая длина введенных данных, а не максимальный размер для этого столбца. Вот почему varchar обычно чаще используется, когда необходимо хранить данные типа символов/текста и сохранять неиспользуемую память для будущего использования.

Недавно я узнал, что... в случае IBM DB2, если вы используете любой столбец varchar в середине остальных столбцов таблицы, тогда размер хранения символов в этом конкретном столбце равен исходному размеру varchar столбец.

ПРИМЕР: если в таблице есть 3 таких столбца:

  1. имя: char(50)
  2. фамилия : varchar(50)
  3. адрес электронной почты: символ (50)

Итак, теперь, если вы хотите сохранить этот текст («Маджхи») в столбце «lastName», который имеет тип данных varchar(50), тогда он займет полный размер хранилища 50 символов, а не только 5 символов, что является фактическим размером фактического текста ( «Маджи»).

Вот почему в IBM DB2 включение любого столбца типа данных varchar в середину остальных столбцов таблицы также работает так же, как работает char тип данных. Таким образом, оптимизации памяти не происходит.

Итак, я просто хочу знать, работает ли наш MySQL таким же образом, или он не различает, где когда-либо существует столбец varchar dataype и работает соответственно, поскольку должен работать столбец varchar datatype.


mysql db2 varchar
person Suresh    schedule 18.01.2012    source источник
comment
Ваше утверждение о том, что DB2 будет хранить «Маджи», используя 50 символов в varchar(50), если это поле находится в середине строки, неверно. Потребуется 9 байт - 5 для фактического значения и 4 байта для хранения длины строки. Если столбец допускает значение null, для нулевого индикатора будет еще 1 байт.   -  person Ian Bjorhovde    schedule 18.01.2012

Ответы (1)


arrow_upward
2
arrow_downward

Здесь есть два аспекта.

Во-первых, это хранилище на диске. В этом случае для каждой строки хранится столько данных, сколько необходимо, и не важно, есть ли какие-либо другие столбцы после varchar или нет.

Второй — это таблица, загруженная в память. В этом случае MySQL внутренне преобразует VARCHAR(n) в CHAR(m)[1], где m — максимальная длина данных в данном столбце. Таким образом, если ваш столбец объявлен VARCHAR(60), но самая длинная хранящаяся в нем строка имеет длину 10, то поле в памяти будет иметь фиксированную длину 10. Это приводит к компромиссу между минимизацией занимаемой памяти и максимизацией производительности доступа к данным (проще получить конкретный столбец, если вы знаете, где он начинается).

[1]: здесь некоторое упрощение. На самом деле это не CHAR или любой другой тип данных MySQL.

person Mchl    schedule 18.01.2012
comment
Дополнительным соображением является Unicode. Количество байтов может быть больше, чем количество символов как в памяти, так и на диске. - person zarchasmpgmr; 19.01.2012