Есть ли смысл использовать CHAR, если у вас есть VARCHAR в той же таблице? - PullRequest
Новая
       29

Есть ли смысл использовать CHAR, если у вас есть VARCHAR в той же таблице?

5 голосов
/ 08 февраля 2011

Я только что прочитал принятый ответ на этот вопрос , который оставил мне этот вопрос.

Вот цитата из этого ответа:

"Но так как вы пометилиВ этом вопросе о MySQL я упомяну специфический для MySQL совет: когда ваш запрос неявно генерирует временную таблицу, например, во время сортировки или поля GROUP BY, VARCHAR преобразуются в CHAR, чтобы получить преимущество работы сстроки фиксированной ширины. Если вы используете много полей VARCHAR(255) для данных, которые не должны быть такими длинными, это может сделать временную таблицу очень большой. "

Насколько я понимаю, преимуществоиз CHAR - это то, что вы получаете строки фиксированной ширины, так что VARCHAR в той же самой таблице запутался?Есть ли преимущества использования CHAR, если у вас есть VARCHAR в той же таблице?

Вот пример:

Таблица с CHAR: 

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    street VARCHAR(100) NOT NULL,
    postcode CHAR(8) NOT NULL,
    PRIMARY KEY (id)
);

Таблица без CHAR: 

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    street VARCHAR(100) NOT NULL,
    postcode VARCHAR(8) NOT NULL,
    PRIMARY KEY (id)
);

Будет ли таблица с CHAR работать лучше таблицы без CHAR, и если да, то в каких ситуациях?

1 Ответ

2 голосов
/ 09 февраля 2011

"VARCHAR" в основном устанавливает максимальную длину поля и сохраняет только те данные, которые в него введены, тем самым экономя место. Тип "CHAR" имеет фиксированную длину, поэтому, если вы установите "CHAR(100)", будет использовано пространство из 100 символов независимо от содержимого.

Единственный раз, когда вы получите преимущество в скорости, - это если в вашей записи нет полей переменной длины ("VARCHAR", "TEXT" и т. Д.). Вы можете заметить, что Внутренне все ваши поля "CHAR" заменяются на "VARCHAR", как только MySQL добавляет тип поля переменной длины.

Также "CHAR" менее эффективен с точки зрения пространства хранения, но более эффективен для поиска и добавления. Это быстрее, потому что база данных должна только читать значение смещения, чтобы получить запись, а не читать части, пока не найдет конец записи. А записи фиксированной длины сведут к минимуму фрагментацию, поскольку удаленное пространство записи можно повторно использовать для новых записей.

Надеюсь, это поможет.

...