Ответ
CHAR и VARCHAR — строковые типы данных, но с разной стратегией хранения, что влияет на производительность и использование памяти.
CHAR(n) — строка фиксированной длины.
- Всегда занимает ровно
nсимволов в памяти/на диске. - Если строка короче, она дополняется пробелами справа (padding).
- Быстрее для чтения/записи, если длина данных постоянна, из-за предсказуемости размера записи.
VARCHAR(n) — строка переменной длины.
- Занимает столько места, сколько нужно для хранения строки + небольшие служебные данные (обычно 1-2 байта для хранения длины).
- Пробелы в конце не добавляются и не обрезаются автоматически.
- Экономит место на диске и в памяти для строк разной длины.
Сравнительная таблица:
| Действие | CHAR(10) |
VARCHAR(10) |
|---|---|---|
INSERT 'abc' |
Сохраняется как 'abc ' (7 пробелов). |
Сохраняется как 'abc' (3 символа + служебные байты). |
SELECT LENGTH() |
Всегда возвращает 10. | Возвращает 3 (фактическую длину). |
| Использование | Коды (страны 'RU', 'US'), фиксированные форматы (номера ИНН). |
Имена, email, адреса, описания — где длина сильно варьируется. |
Пример запроса:
CREATE TABLE users (
country_code CHAR(2), -- Всегда 2 символа
username VARCHAR(50), -- До 50 символов, занимает по факту
bio VARCHAR(500) -- Длинный текст переменной длины
);
INSERT INTO users VALUES
('US', 'alice', 'Hello!'), -- CHAR дополнен пробелами, VARCHAR нет
('GB', 'bob_very_long_username', 'A long biography...');Рекомендация: Используйте CHAR только для данных с гарантированно одинаковой длиной. Во всех остальных случаях VARCHAR эффективнее.
Ответ 18+ 🔞
Давай разберёмся с этими двумя типами, а то народ постоянно нихуя не понимает и потом удивляется, почему база тормозит как в говне.
Вот смотри, CHAR и VARCHAR — это как два разных подхода к хранению текста. Один — максималист и зануда, другой — гибкий и экономный. И выбор между ними — это не просто так, от хуйни, это реально влияет на то, сколько места сожрёт твоя база и как быстро она будет работать.
CHAR(n) — это строгость и порядок, блядь.
- Он всегда, сука, занимает ровно
nсимволов. Не меньше, не больше. Как солдат в строю. - Записал ты туда слово "abc"? А он тебе его дополняет пробелами до нужной длины, вот так:
'abc '. Просто потому что может, епта. - Зато быстрее, если длина данных всегда одинаковая. Компьютер знает точно, где что искать, не надо голову ломать.
VARCHAR(n) — это рациональность и экономия.
- Он занимает ровно столько места, сколько нужно твоей строке, плюс пару байтов служебных (чтобы помнить, какая длина).
- Записал "abc"? Он и сохранит "abc". Никаких лишних пробелов, никакого паддинга. Честно.
- Место экономит знатно, особенно если у тебя данные разной длины. Это его главный козырь.
Короче, таблица для наглядности, а то словами долго:
| Что делаем | CHAR(10) (Зануда) |
VARCHAR(10) (Экономный) |
|---|---|---|
INSERT 'abc' |
Сохраняет как 'abc ' (7 пробелов, нахуй не нужных). |
Сохраняет как 'abc' (3 символа и всё, чин чином). |
SELECT LENGTH() |
Вернёт 10. Всегда. Даже если ты впихнул туда одну букву. | Вернёт 3. Потому что реальная длина — три символа, ёпта. |
| Где юзать | Коды стран ('RU', 'US'), номера (ИНН), любые фиксированные форматы. |
Имена, почты, адреса, описания — всё, где длина пляшет от "одно слово" до "овердохуища текста". |
Пример, чтобы вообще всё стало ясно:
CREATE TABLE users (
country_code CHAR(2), -- Код страны — всегда два символа. Идеально для CHAR.
username VARCHAR(50), -- Имя пользователя — кто-то 'alice', а кто-то 'xX_Программист_1991_Xx'. VARCHAR рулит.
bio VARCHAR(500) -- Биография. Тут и говорить нечего — однозначно VARCHAR, ибо текст.
);
INSERT INTO users VALUES
('US', 'alice', 'Hello!'), -- 'US' дополнен до 2 символов (хотя он и так 2), а 'alice' и 'Hello!' сохранены как есть.
('GB', 'bob_very_long_username', 'A long biography...');Итоговая рекомендация, блядь: Не умничай. Если данные ВСЕГДА одной и той же, блять, длины — бери CHAR. Во всех остальных, ебать, 99.9% случаев — смело суёшь VARCHAR и не паришься. Сэкономишь кучу места и не будешь потом удивляться, почему у тебя в CHAR(255) хранится логин из трёх букв и 252 пробела.