Выбор типов данных MySQL для схемы рядом с 1С‑Битрикс

Зачем это в контексте Битрикс

Платформа хранит данные в MySQL: свойства элементов, пользователей, заказы и каталог. Тип столбца определяет размер строки в InnoDB, возможности индекса и стоимость сравнений — то есть нагрузку там же, где вы видите «тормоза» в списках и отчётах. Ниже — практичные правила выбора типов без копирования чужих DDL слепо: на копии базы проверяйте план запросов и реальный профиль данных.

Базовые принципы

• Меньше по размеру — лучше: узкие строки меньше грузят буферный пул и сортировки.
• Проще тип — лучше: целое сравнивается дешевле, чем строка той же «логической» длины.
• NOT NULL по умолчанию: для индексов предсказуемее, не тратится работа на трёхзначную логику NULL; «пустое» лучше кодировать отдельным значением (например, 0 или пустая строка там, где это осмысленно по доменной модели).

Официальный обзор влияния размера типов на хранение есть в документации MySQL.

Числа: INT, плавающая точка, DECIMAL

Семейство TINYINT … BIGINT и INT UNSIGNED — основной запас для счётчиков, внешних числовых ключей справочников и флагов в узких полях. INT(N) в MySQL не задаёт диапазон хранения, а влияет лишь на отображение с ZEROFILL — для схемы полезнее думать именно о типе и знаковости.

Для плавающей точки чаще выбирают FLOAT, если двойная точность DOUBLE избыточна: меньше трафика и места. Деньги, скидки, налоги в торговом каталоге безопаснее держать в DECIMAL(p,s), чтобы не ловить ошибки двоичной арифметики — это же касуется кастомных таблиц рядом с b_sale_*, если вы не проксируете всё через API модуля Sale.

CHAR и VARCHAR

CHAR(n) уместен для коротких строк фиксированной длины (коды валют, хэши фиксированной длины) — меньше накладных расходов на длину. У CHAR пробелы в конце обрезаются при сравнении по правилам padding.

VARCHAR хранит длину отдельно (1–2 байта) и экономит место, если средняя длина мала; обновления могут стоить дороже при сильном изменении длины. Длинный произвольный текст — VARCHAR с разумным лимитом; если типичная строка намного короче максимума, переплата по строкам таблицы ниже, чем у «надутого» фиксированного поля.

TEXT и BLOB

Подтипы TINYTEXT … LONGTEXT и бинарные BLOB в InnoDB часто уносят данные из основной записи в отдельное хранилище off-page: для тяжёлых выборок это может означать лишние чтения. Сортировка по TEXT учитывает только префикс длины max_sort_length. Индекс по такому полю обычно префиксный — проектируйте селективность явно.

Для больших HTML-описаний разумно сразу заложить LONGTEXT, чтобы не упираться в потолок TEXT (~64 КБ логического текста с учётом кодировки) на длинных описаниях товара или статьи. По возможности не дублировать гигантские тексты в таблицах, которые читаются в каждом списке — нормализация «анкета в одной строке, тело в соседней» всё ещё актуальна.

DATETIME и TIMESTAMP

TIMESTAMP компактнее и привязан к часовому поясу сессии; для «момента события» часто удобен. DATETIME занимает больше и не зависит от таймзоны сервера — удобнее для «календарных» дат без привязки к UTC. Нижняя граница TIMESTAMP — 1970 год, верхняя в 32-битной традиции упирается в 2038; для дат рождения и далёких планов выбирайте DATETIME или явную схему хранения даты в приложении.

Автоподстановка DEFAULT CURRENT_TIMESTAMP и ON UPDATE для обоих типов в современных версиях согласована лучше, чем в старых выпусках 5.x; всё равно фиксируйте ожидания в миграциях и проверяйте на стенде с той же версией MySQL, что и прод.

Итог

Выбор типа — это сделка между размером строки, семантикой и стоимостью запросов. Для проектов на Битрикс имеет смысл выровнять кастомные таблицы с теми же дисциплинами, что и ядро: осмысленные NOT NULL, деньги в DECIMAL, тяжёлый текст отделён от «узких» выборок, даты согласованы с таймзоной витрины.