Сравнение схем MySQL: dev и prod в проекте на Битрикс

Зачем сравнивать схему

В 1С‑Битрикс ядро и модули создают таблицы при установке и обновлениях, но на реальных проектах появляются кастомные таблицы, ручные ALTER, индексы под отчёты и обмены. Перед выкаткой на прод полезно убедиться, что «эталонная» схема на тесте совпадает с тем, что реально ждёт код — и наоборот, поймать дрейф после правок на бою.

Идея: два файла только со структурой

mysqldump умеет выгрузить определения таблиц, представлений, триггеров и процедур без строк данных. Тогда diff остаётся читаемым и не тащит гигабайты b_iblock_element_property.

Минимальный сценарий

Подставьте свои имена баз и учётки; для удалённого сервера добавьте -h и параметры SSL по политике хостинга.

#!/usr/bin/env bash
set -euo pipefail

# «Тест» и «бой» — разные logical_database
mysqldump -u user -p --routines --events --triggers \
  --no-data --skip-comments bitrix_stage > schema-stage.sql
mysqldump -u user -p --routines --events --triggers \
  --no-data --skip-comments bitrix_prod > schema-prod.sql

diff -u schema-stage.sql schema-prod.sql || true

Что дают флаги

• --no-data — только DDL, без INSERT.
• --skip-comments — меньше шума от меток времени в шапке (при необходимости уберите, если комментарии важны для аудита).
• --routines / --events / --triggers — не забыть хранимки и триггеры, если они есть в кастомных модулях или для репликации отчётов.

Практика для Битрикс

Сравнивайте одинаковую мажорную версию MySQL и одинаковый набор модулей: иначе diff покажет отличия ядра, а не ваши миграции. Для автоматизации CI часто фиксируют «золотой» schema-golden.sql после чистого развёртывания и в merge-request гоняют diff к нему или между веткой и стейджем.

Ограничения

Порядок объектов в дампах может меняться между версиями утилиты — иногда полезнее сравнивать через специализированные инструменты или разбить по таблицам. Дифф не заменяет проверку прав и sql_mode на целевом сервере.