5
Есть ли разница в производительности между varchar(1) и char(1)? Какая RDBMS обрабатывает эти два типа данных и размеры по-разному?производительность между varchar (1) против char (1)
A
ответ
3
В большинстве случаев разница будет незначительной. Сосредоточьте свои усилия, ориентированные на производительность, в тех местах, где это будет иметь реальное значение, например, составление таблицы и дизайн индекса.
Это помогает разделить проектные усилия на два уровня: логический дизайн и физический дизайн.
Большая часть усилий, ориентированных на производительность, находится на втором этапе, физическом дизайне.
В логическом дизайне гибкость превосходит производительность. За исключением случаев, когда этого не происходит.
1
Это вряд ли имеет значение, так как вы используете 1 байт в обоих случаях.
но длинный рассказ короткий, varchar - переменный размер & шар фиксированный размер. в больших количествах это может повлиять на пространство памяти, а также повлиять на время вычисления.
выступление мудрый, использование char если данные фиксированный длина. если вы гибки в разной длине своих данных, используйте varchar.
+3
*** НЕ 1 байт в обоих случаях! *** - Например, - MYSQL v5.0 docs говорит, что требования к хранению varchar для varchar (M) требуют «L + 1 байт, если значения столбца требуют 0 - 255 байт» (где L представляет фактическую длину в байтах заданного строковое значение). Итак, вы должны использовать 1 байт для CHAR (1) и 2 байта для VARCHAR (1). В этом случае вы используете на 100% больше места для хранения этого столбца. Это может быть или не быть большой сделкой в зависимости от ситуации использования. Стоит отметить разницу, хотя в случае, если это уместно. (см. Http://dev.mysql.com/doc/refman/5.0/ru/storage-requirements.html) –
2
Что касается Oracle касается ....
CHAR (2) всегда будет использовать два байта/символы хранения. VARCHAR2 (2) может использовать только один. Поэтому общий случай - использовать VARCHAR2 вместо CHAR.
На практике вы не должны видеть разницу в производительности для столбца с одним символом.
Поскольку никогда не бывает преимуществ от CHAR, я всегда использую VARCHAR2.
+4
В varchar все равно придется хранить как минимум байт для длины строки, тем не менее, поэтому у вас никогда не может быть менее 1 байт. – Gabe
0
Мое понимание после прочтения описания MySQL VARCHAR и CHAR заключается в том, что если данные всегда будут иметь одинаковую длину, тогда CHAR может потенциально сохранить вам один байт данных, поскольку VARCHAR требует хранения отдельного байта от фактических данных, чтобы фиксировать, сколько времени данные. Однако, если вы не постоянная длина данных, и вы думаете о соображениях пространства, имеет смысл использовать VARCHAR, потому что CHAR всегда будет использовать байт для каждого бита объявленной длины, есть ли что-либо в этом пространстве ,
В конце концов, однако, это, вероятно, не делает такой большой разницы, так как количество данных, занимаемых, довольно мало.
Здесь я получил информацию: http://dev.mysql.com/doc/refman/5.0/en/char.html Если вы переходите по ссылке, обратите особое внимание на маленькую диаграмму, так как она дает примеры того, как данные будут обрабатываться с помощью VARCHAR vs. CHAR.
3
В MS SQL VARCHAR (1) использует три байта хранения, а CHAR (1) использует один байт хранилища.
CHAR (1) более эффективен, чем VARCHAR (1) в обработке и хранении.
Точка безубыточности на VARCHAR была бы чем-то большим, чем 3 символа, если вы используете данные переменной длины.
Если использовать фиксированную длину, то CHAR всегда более эффективен с помощью двух байтов.
0
Для Oracle
The (1) VARCHAR2 и СИМ (1) идентичны во всех аспектах. Не существует убедительной причины использовать тип CHAR в этом случае, и во избежание путаницы я просто говорю «нет» даже для поля CHAR (1).
Ссылка: https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2668391900346844476
Гибкость должна почти никогда не превосходить производительность! Я гарантирую, что пользователь хочет добиться максимальной гибкости, даже если они говорят, что хотят гибкости. – HLGEM