Индексы и производительность — теги index и uniqueIndex, составной индекс и EXPLAIN в GORM

Индекс — служебная структура, чаще всего B-tree, сбалансированное дерево, которое СУБД держит рядом с таблицей и обновляет при каждой записи. Поиск по дереву стоит логарифм от размера таблицы, полный проход — линейный: на тысяче строк разница незаметна, на миллионе — это разница между «мгновенно» и «секунды». В GORM индекс живёт не в SQL-скрипте, а в теге поля: gorm:"index" — и AutoMigrate из четвёртого урока достроит его отдельным CREATE INDEX, если его ещё нет. Поисковый запрос «индексы базы go» обычно приводит не в раздел GORM, а в мануалы PostgreSQL и MySQL — и это честно: GORM не строит деревья сам, он переводит теги в DDL конкретной базы, а быстрый или медленный план построит уже планировщик СУБД. Поэтому урок двуслоен: нижний слой — механика тегов внутри GORM (schema/index.go и мигратор), верхний — то, что эти теги значат для базы: составные ключи, частичные предикаты, EXPLAIN и цена записи. План тот же, что и в предыдущих уроках: от простого к дорогому, и всё — на каноне TodoItem, который мы начали собирать ещё в третьем уроке.

Механика — в schema/index.go. Разбором схемы заведует ParseIndexes: она проходит по полям структуры и берёт те, у которых в TagSettings есть INDEX или UNIQUEINDEX — то есть любые теги gorm:"index" и gorm:"uniqueIndex" в любом месте общего тега поля. Для каждого поля parseFieldIndexes режет значение тега по точке с запятой (поэтому одно поле может участвовать в нескольких индексах) и выделяет индексные секции: имя — всё до первой запятой, дальше — настройки, которые ParseTagSetting раскладывает в карту с ключами капсом; экранированная запятая \, склеивается обратно, так что дока пишет comment:hello \, world без страха разрезать комментарий. Имя пустое — не беда: его генерирует namer.IndexName(table, subName), а в naming.go это formatName("idx", таблица, колонка) — отсюда формула автоимени idx_таблица_колонка, знакомая по четвёртому уроку: idx_todo_items_priority. Итог разбора — структура Index{Name, Class, Type, Where, Comment, Option, Fields}: в комментариях исходников Class — это UNIQUE | FULLTEXT | SPATIAL, Type — btree, hash, gist, spgist, gin и brin. Каждая колонка попадает в Fields как IndexOption{Expression, Sort, Collate, Length, Priority} — в исходниках у Sort комментарий DESC, ASC, то есть направление — это настройка колонки, а не часть имени. Поля одного индекса дописываются в порядке объявления структуры, затем slice сортируется по Priority по возрастанию — младший приоритет становится первой колонкой индекса; равные приоритеты оставляют порядок полей структуры, как и обещает дока, а без настройки вовсе приоритет — десять: в исходниках ошибка strconv.Atoi записывает priority = 10.

Дока формулирует связь коротко: uniqueIndex works similar like index, it equals to index:,unique. В исходниках то же самое: если ключ тега UNIQUEINDEX или в настройках встретился UNIQUE, parseFieldIndexes записывает settings["CLASS"] = "UNIQUE" — и шаблон CREATE <class> INDEX мигратора выведет CREATE UNIQUE INDEX. Отсюда обе доковские формы: голый uniqueIndex и именованный uniqueIndex:idx_name,sort:desc — да, уникальному индексу доступна вся та же карта настроек, включая направление. Но рядом в доке стоит оговорка: Note that this will not work for unique composite indexes — уникальный составной индекс собирается не тегом uniqueIndex на каждом поле, а общим именем с настройкой unique: gorm:"index:idx_member,unique" на каждом из полей. Вторая тонкость — разница с тегом unique, который стоит на Slug в модели четвёртого-пятого уроков: unique ставит field.Unique (в исходниках utils.CheckTruth(tagSetting["UNIQUE"])) и превращается в ограничение колонки в её типе, uniqueIndex — отдельный объект CREATE UNIQUE INDEX. В field.go про это честный комментарий: In some db (e.g. MySQL), Unique and UniqueIndex are indistinguishable — при миграции колонок мигратор сверяет фактическую уникальность с моделью (MigrateColumnUnique) и на расхождение отвечает AlterColumn. И связка с пятым уроком, которую теперь видно целиком: именно уникальный индекс рождает знакомую ошибку вставки дубликата — 23505 в PostgreSQL, 1062 Duplicate entry в MySQL, — а upsert-оговорка пятого урока целится ровно в этот объект базы.

Составной индекс в GORM — это не отдельный тег, а следствие общего имени: дока говорит Use same index name for two fields will creates composite indexes и показывает idx_member из Name и Number с порядком колонок name, number. Уникальная версия — та же пара тегов с настройкой unique: gorm:"index:idx_member,unique" на каждом поле — тогда дубликат пары значений станет невозможен, и в этот объект попадёт ошибка вставки из пятого урока. Почему порядок колонок — не вкусовщина, дока произносит прямо: The column order of a composite index has an impact on its performance so it must be chosen carefully. Правило B-tree: колонки-равенства ставятся вперёд, сортировки и диапазоны — следом. Для ленты канона это (done, created_at desc): равенство done = false работает как точка входа в дерево, а внутри одного значения done строки уже лежат в порядке created_at — базе остаётся отрезать LIMIT 10. Индекс (created_at, done) тоже найдёт нужные строки, но лежат они в нём в порядке времени по всем значениям done вперемешку — полезный префикс короче, работы больше. Механика порядка — priority: дока определяет её одной строкой — the default priority value is 10, if priority value is the same, the order will be based on model struct's field index (в исходниках ошибку strconv.Atoi отдаёт та же десятка), а разборщик сортирует колонки по возрастанию приоритета. Доковские примеры стоит проговорить дословно: priority:2 против priority:1 даёт порядок number, name; priority:12 против тега без priority — тот же порядок number, name, потому что 10 меньше 12. Для встраиваемых структур с повторяющимся составным индексом у доки отдельный приём: тег composite задаёт часть имени — Foo с composite:myname получит idx_foo_myname, встроившая её Bar0 — idx_bar0_myname; работает composite только когда явного имени в теге нет.

Кроме имени и priority, в индексной секции тега живут ещё восемь настроек — дока перечисляет их списком: class, type, where, comment, expression, sort, collate, option. Теперь по каждой видно место в DDL, потому что шаблон создания лежит в миграторе: CreateIndex собирает строку по шаблону из исходников — CREATE, class, INDEX ? ON ?? (имя и таблица), потом USING type, затем COMMENT и option. Комментарии исходников подтверждают словарь: Class — это UNIQUE | FULLTEXT | SPATIAL (полнотекстовые и пространственные индексы MySQL), Type — btree, hash, gist, spgist, gin и brin (структуры PostgreSQL). Сами колонки печатает BuildIndexOptions: имя колонки — в кавычках диалекта; настройка expression заменяет имя целиком (индекс по выражению), length дописывает префикс name(N) — MySQL-овская индексация начала строки; collate и sort добавляются суффиксами после имени. Направление sort:desc из канона — это ровно этот суффикс: колонка с desc в DDL. Разбор настроек идёт через ParseTagSetting, ключи капсулятся, а экранированная запятая \, позволяет держать запятую внутри значения — живой пример из доки: comment:hello \, world. Осталась самая интересная настройка — where: она не про форму индекса, а про то, какие строки в него попадают; ей посвящён следующий блок, как и вопросу, когда такое сужение выгодно.

Частичный индекс — индекс не по всей таблице, а только по строкам, подходящим под предикат; в теге это настройка where:, и оба доковских примера её используют: where:name3 != 'jinzhu' и where:age > 10. Для канона случай хрестоматийный: лента ищет только невыполненные задачи, а выполненные (done = true) в выборках не участвуют никогда — значит, и дерево по ним не нужно. Вешаем на CreatedAt тег gorm:"index:idx_open,where:done = false" — и в DDL уезжает CREATE INDEX ... ON todo_items (created_at) WHERE done = false. Выигрыш тройной: индекс меньше по размеру, каждая вставка выполненной задачи его не трогает, и все записи дерева — только «живые» строки. Цена тоже честная: планировщик применит частичный индекс, только когда сможет вывести его предикат из вашего WHERE — запрос с литералом done = false попадает точно, а запрос вида WHERE done = ? с параметром СУБД сверит по значению конкретного прогона (PostgreSQL на первом выполнении строит custom plan — обычно это работает в вашу пользу). Вторая цена — практика ревью: предикат живёт внутри DDL, и без AutoMigrate-лога его не видно; в четвёртом уроке мы договаривались смотреть SQL в ревью миграций — частичный индекс тот случай, когда это не пунктуальность, а необходимость. База знаний: если предикат перестал соответствовать запросам, индекс молча перестанет использоваться — без ошибок, только по замедлениям.

Что происходит при перезапуске сервиса? AutoMigrate в миграторе проходит по разобранным индексам схемы и для каждого проверяет HasIndex, и только если индекса нет — вызывает CreateIndex; проверка идёт по information_schema.statistics. Перезапуски ничего не задублируют, но и лишней работы не будет: индекс на месте — CREATE INDEX не выпустится. Внутри HasIndex есть деталь, которая спасает от опечаток: аргумент сначала прогоняется через LookIndex, который находит индекс и по имени, и по имени поля — HasIndex(&TodoItem{}, "Done") вернёт правду про idx_done_created, а выдуманное имя честно даст false. При создании таблицы с нуля индексы строятся после таблицы: у диалекторов PostgreSQL и SQLite настройка CreateIndexAfterCreateTable стоит true, мигратор откладывает CreateIndex defer-ом до успеха CREATE TABLE; MySQL собирает индексы прямо внутрь CREATE TABLE. Ручной интерфейс из доковского Migrator: CreateIndex, DropIndex, HasIndex, RenameIndex (переименование — ALTER TABLE ... RENAME INDEX). Зачем это руками, если AutoMigrate сам? Два случая. Первый: тяжёлая таблица продакшена, где индекс нужно строить с опцией CONCURRENTLY — вне окна миграции, отдельным шагом с ревью. Второй: снятый с модели индекс — AutoMigrate удалять ничего не будет, это против его договорённости «ничего не терять», DropIndex вызывается руками. Карта самого AutoMigrate целиком осталась в четвёртом уроке — здесь мы вытащили только индексную его часть.

EXPLAIN — команда вашей СУБД, а не GORM: библиотека не прогоняет планы сама, она лишь показывает сгенерированный SQL, который вы и отдаёте планировщику. Словарь PostgreSQL, которого хватит на 90 % случаев: Seq Scan — полный проход по таблице; Index Scan — поиск по дереву с заходами в таблицу за остальными колонками; Bitmap Index Scan вместе с Bitmap Heap Scan — индекс строит битовую карту подходящих строк, затем куча читается одним заходом; Index Only Scan — все нужные запросу колонки уже лежат в индексе. EXPLAIN без слов просто показывает план и ничего не исполняет; EXPLAIN ANALYZE реально выполняет запрос и печатает фактическое время и число строк на каждом узле — это уже дорогая операция, а на изменяющих запросах (INSERT, UPDATE, DELETE) она честно их выполнит, так что на проде её обкладывают транзакцией с откатом. Как проверить GORM-запрос: включите логгер при открытии базы (gorm.Config с Logger в режиме Info), скопируйте SELECT из следа и выполните в psql с EXPLAIN ANALYZE. На узле-скане целевой таблицы должно произойти одно из двух: либо Seq Scan сменился на Index Scan с Index Cond по вашему индексу, либо планировщик вправе отказал — маленькая таблица, слабая селективность (done = false при девяноста пяти процентах таких строк — проще прочитать почти всё). Индекс — предложение планировщику, а не приказ; EXPLAIN — способ услышать ответ.

Каждый индекс — вторая структура, которую база обязана поддерживать при каждой вставке, каждом удалении и каждом апдейте, затрагивающем индексные колонки. Пять индексов на таблице — пять дополнительных правок дерева на каждую строку; в цикле вставок это видно по таймингам даже без профайлера, а на диске индексы живут своей жизнью и занимают место, сопоставимое с данными. Отсюда три линии гигиены. Первая: индекс заводят под конкретный запрос, а не под поле «на всякий случай» — гипотетические индексы тормозят все вставки ради несуществующего SELECT. Вторая: не дублировать префиксы — отдельный индекс на done при существующем составном (done, created_at) бесполезен: левый префикс составного уже отвечает на фильтр по done, а каждая лишняя структура — та же надбавка к записи. Третья: следить за жизненным циклом — индекс, снятый с модели, AutoMigrate не удаляет (его договор «ничего не терять» из четвёртого урока), и мёртвый индекс будет платить налог на запись вечно, пока вы не вызовете DropIndex руками. Проверка выгоды всегда замером: EXPLAIN ANALYZE до и после для чтения, тайминги вставки для записи — решение принимается по цифрам, а не по ощущениям. И помните про выборочность: индекс на колонку с двумя значениями почти всегда дешевле пропустить — B-tree по done мало что отсекает, составной с done в роли равенства — да, потому что отсекать начинает вторая колонка.

Теперь promise семнадцатого урока можно закрыть формулой. Keyset-пагинация выигрывает у offset именно поиском по индексу: WHERE id < ? ORDER BY id DESC LIMIT n без индекса на сортировочном ключе — это Seq Scan всей таблицы и сортировка всех подходящих строк ради десяти; с индексом — спуск по дереву от курсора, логарифм на любой глубине страницы. Первичный ключ индексирован всегда, поэтому keyset по id работает из коробки; курсор по времени (лента с тай-брейком ORDER BY created_at DESC, id DESC) уже требует составного индекса — и наш idx_feed из середины урока собран ровно под неё: done как равенство, created_at desc как порядок, id как тай-брейк. Уберите любую из трёх колонок — и keyset либо потеряет фильтр, либо потеряет порядок, либо начнёт терять строки на границе курсора. С offset-страницами индекс тоже дружит, но меньше: OFFSET 100000 всё равно прочтёт сто тысяч записей дерева — просто из дерева, а не из таблицы; поэтому для глубоких лент совет семнадцатого урока не меняется: keyset. И последний мостик: приём «запасной строки» n+1 для метки HasNext едет по тому же индексу — лишняя строка достаётся почти бесплатно, только если дерево отдаёт строки в нужном порядке. Скорость keyset — это скорость индекса; два урока — одна связка.

Индексы держатся за соседние темы курса. Keyset-пагинация и метка HasNext, которым индекс нужен как воздух, разобраны в семнадцатом уроке про пагинацию, карта AutoMigrate и договор «ничего не терять» — в четвёртом уроке про миграции; там же — модель, из которой здесь выросли теги. Ошибка уникальности 23505 и upsert-оговорка остались в пятом уроке — теперь вы знаете, какой объект базы за ними стоит. Дальше по маршруту: девятнадцатый урок «Скоупы и переиспользование запросов» развернёт скопы — на них построен пагинатор из семнадцатого, и наши индексные запросы самое время будет упаковать в переиспользуемые фильтры. Карта всех двадцати пяти уроков — на странице курса. Домашка ниже прогоняет полный цикл: тег, DDL, план, замер.