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

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

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

Первичный ключ и суррогаты

Для суррогатного идентификатора в InnoDB типична связка INT или BIGINT с AUTO_INCREMENT: компактное значение, предсказуемый порядок вставок. Строковые первичные ключи длиннее в индексе и дороже сравнивать; для «естественных» ключей вроде артикула часто оставляют числовой PK и выносят уникальность в отдельный индекс.

Случайные строки (MD5, UUID в текстовом виде) ухудшают локальность данных: соседние по смыслу строки разъезжаются по B‑дереву. Если нужен UUID, рассмотрите хранение в BINARY(16) (например, через UNHEX() при вставке) вместо 36 символов с дефисами.

В InnoDB таблица физически организована вокруг кластерного индекса — обычно это первичный ключ. Вторичные индексы хранят ключ кластера, поэтому «лишний» первичный ключ из длинной строки раздувает и вторичные структуры.

B‑дерево: как используется в запросах

B‑дерево — основной тип в MySQL для типичных сценариев. Им удобно искать по полному значению, по левому префиксу составного ключа, по интервалу для первой колонки ключа после фиксации предыдущих равенствами, а также опираться на ключ при сортировке, если порядок ORDER BY совпадает с порядком колонок в индексе (с оговорками про смешанный ASC/DESC в старых версиях).

Ограничения: поиск «с конца» строки (суффикс) без специальных приёмов индекс не подхватит; нельзя «перепрыгнуть» левую колонку составного индекса и ждать эффекта на правых полях без условий слева; после условия диапазона (>, BETWEEN) на колонке дальнейшие колонки того же индекса в части диапазона часто уже не используются так, как при равенствах.

Хэш и точное совпадение длинной строки

Хэш‑индекс ускоряет равенство по полному значению, но не подходит для сортировки, префиксов и диапазонов. На практике в MySQL чаще встречают эмуляцию: отдельное целочисленное поле с быстрым хэшем (например, CRC32) и точная проверка исходной строки в WHERE, чтобы отсечь коллизии.

Принцип изолирования колонок

Индекс не помогает, если столбец «обёрнут» в функцию или арифметику: оптимизатор видит выражение, а не чистое поле. Пишите условие так, чтобы слева оставалось имя колонки, а вычисления переносились на константу справа (даты, смещения, мультивыборы по границам интервала).

Префиксные индексы и селективность

Для длинных VARCHAR иногда создают индекс по префиксу фиксированной длины, чтобы сэкономить место. Имеет смысл оценивать селективность: отношение числа уникальных значений к числу строк; слишком короткий префикс даёт мало отличий, слишком длинный — мало выигрыша к полному индексу.

Покрывающие индексы и дубликаты

Если все нужные в SELECT столбцы присутствуют в индексе (для InnoDB — с учётом особенностей вторичного ключа и кластера), сервер может обойтись без чтения полной строки — быстрее и дешевле по I/O. Избыточные и дублирующие индексы (одни и те же колонки в том же порядке или один ключ полностью покрывается другим) увеличивают стоимость вставок и обновлений; перед добавлением нового имени полезно проверить, не расширит ли уже существующий составной индекс задачу.

Порядок полей в составном индексе

Частая эвристика: сначала колонки с равенствами и лучшей селективностью, затем те, по которым реально нужен диапазон или сортировка. Текст условий в WHERE произвольен для оптимизатора; важен смысл и соответствие левому префиксу индекса. Для JOIN и сортировок учитывайте реальные отчёты и списки в админке — не только «канонический» один запрос.

Что делать в проекте

• Фиксируйте медленные запросы и разбирайте план на копии данных.
• Избегайте функций над индексируемыми полями в условиях.
• Согласуйте миграции индексов с дежурными окнами: ALTER на больших таблицах может быть долгим.
• После изменений сравните не только время, но и объём буферного пула и дисковую нагрузку.

Соединение классической теории индексов с практикой Битрикс — это не разовый «волшебный CREATE INDEX», а итерация: измерение, гипотеза, проверка, документирование схемы.