Краткий ответ

Нет. В стандартном SQL длина VARCHAR(10) означает не более десяти символов, а не десяти байт. В UTF-8 десять символов могут занимать больше десяти байт, поскольку разные символы имеют разную длину в кодировке.

Однако конкретная СУБД может иметь собственные типы, настройки или ограничения, поэтому для прикладного кода необходимо проверить документацию выбранной системы.

Исторический контекст

SQL отделяет логическое представление текста от способа его физического хранения. Это позволяет задавать ограничение на длину строки в символах, не связывая модель данных с конкретной кодировкой и количеством байт.

Такой подход особенно важен для многоязычных данных: символы разных алфавитов могут занимать различное число байт, но бизнес-правило обычно формулируется именно в символах — например, «название не длиннее 100 символов».

Постановка проблемы

Если разработчик ошибочно принимает VARCHAR(10) за десять байт, он может неверно оценить допустимую длину текста. В UTF-8 десять кириллических символов обычно занимают больше десяти байт, а некоторые символы Unicode — ещё больше.

Обратная ошибка тоже опасна: ограничение в десять символов не гарантирует, что значение уложится в десять байт. Это может привести к переполнению физического лимита строки, индекса или внешнего интеграционного протокола, если такие лимиты измеряются в байтах.

Подробное решение

Для строковых типов нужно различать две характеристики:

длину в символах — сколько символов содержит строка;
размер в байтах — сколько места занимает её представление в выбранной кодировке.

В стандартной модели VARCHAR(n) ограничивает длину в символах. Проверить эти величины можно средствами SQL, если СУБД поддерживает стандартные функции измерения длины:

SELECT
    CHAR_LENGTH('Привет') AS symbols,
    OCTET_LENGTH('Привет') AS bytes;

Для UTF-8 результатом будет шесть символов и двенадцать байт, поскольку каждый кириллический символ в данном слове занимает два байта. Точный размер зависит от конкретного текста и кодировки.

Нужно учитывать, что «символ» в SQL не всегда совпадает с воспринимаемым пользователем графемным кластером. Например, один визуальный знак может состоять из нескольких кодовых точек Unicode, поэтому ограничение по символам не обязательно равно ограничению по пользовательским знакам.

Также нельзя без проверки переносить это правило между СУБД. Некоторые системы или типы используют байтовую семантику длины, а поведение усечения, сравнения и индексации зависит от реализации и настроек. Для пользовательского текста следует отдельно определить требование к длине, кодировке и допустимым Unicode-последовательностям.

Ситуация из практики

В сервисе нужно хранить отображаемое имя пользователя длиной до 80 символов. Команда выбрала VARCHAR(80), считая, что это ограничит размер столбца 80 байтами.

Вариант с байтовым ограничением плохо соответствует требованию: имя из кириллических символов будет отклоняться раньше, чем имя из латиницы. Вариант без ограничения тоже неидеален: база не защищает от чрезмерно длинных значений, а проверка только в интерфейсе может быть обойдена другим клиентом.

Правильное решение — задать ограничение в символах на уровне модели данных, проверить семантику длины в используемой СУБД и отдельно контролировать технические байтовые ограничения при передаче или индексировании. В результате бизнес-правило одинаково работает для разных языков, а инфраструктурные лимиты учитываются явно.

Что кандидаты часто упускают

1. Равно ли число символов числу Unicode-кодовых точек?

Нет. SQL обычно считает символы согласно своей строковой семантике, но визуальный знак может состоять из нескольких кодовых точек: например, буква и комбинируемый диакритический знак. Поэтому для ограничения «не более 20 видимых знаков» одной проверки длины SQL может быть недостаточно; иногда нужна нормализация Unicode и специализированная проверка на уровне приложения.

2. Гарантирует ли ограничение VARCHAR(10) отсутствие проблем с размером индекса?

Нет. Ограничение задаёт максимальную логическую длину, но байтовый размер зависит от кодировки. Индекс на строковом столбце может иметь отдельный предел размера ключа, поэтому допустимое значение столбца не всегда можно безоговорочно использовать в индексе. Нужно проверить лимиты конкретной СУБД и при необходимости выбрать другой ключ, префиксный индекс или отдельный хеш.

3. Что нужно проверить при смене кодировки столбца или базы?

Нужно проверить возможность преобразования всех существующих значений, изменение их байтового размера и правила обработки недопустимых последовательностей. Даже если количество символов не меняется, новая кодировка может требовать больше места или не поддерживать отдельные символы. Миграцию следует выполнять с предварительной валидацией данных и контролем отсутствия усечения или потери информации.