Как MySQL масштабировал ранний веб и живёт в продакшене

Почему MySQL стал базой раннего веба

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

Что раннему вебу было нужно — и что MySQL дал

Ранний веб рос хаотично: сегодня у вас форум на пару тысяч пользователей, завтра — внезапный всплеск трафика после упоминания в СМИ. На этом фоне MySQL закрывал несколько ключевых потребностей.

• Скорость на типовых сценариях. Много простых чтений (ленты, списки, профили), немного записей (комментарии, регистрации) — MySQL справлялся бодро.
• Простота старта. Понятная установка, минимум обязательной настройки, прозрачные SQL‑запросы. Для веб‑разработчика это означало: можно делать продукт, а не месяцами разбираться с инфраструктурой.
• Доступность. Открытая лицензия, поддержка хостингами и провайдерами, огромное сообщество. В итоге MySQL естественно попадал в стандартный стек «Linux + веб‑сервер + база».

Что изменилось за 20+ лет

MySQL не застыл во времени. Появились зрелые практики эксплуатации и инструменты, которые сделали его пригодным для серьёзных нагрузок:

• стандартом для продакшена стал InnoDB;
• нормой стали репликация, резервное копирование без остановок, мониторинг и предсказуемые настройки;
• команды научились масштабировать базы не «героизмом», а процессами: лимиты, нагрузочные тесты, миграции по шагам.

О чём эта статья

Дальше — без «магии»: как MySQL переживает рост нагрузки — от выбора движка и ускорения запросов до репликации, шардинга, высокой доступности и безопасных миграций. Это не учебник по теории баз данных, а практичный взгляд на то, почему MySQL до сих пор живёт в большом продакшене.

Ключевые идеи архитектуры MySQL, понятные без теории

MySQL часто воспринимают как «просто базу данных», но её сила — в понятной модели хранения и доступа к данным. Для веб‑приложений это особенно важно: запросы должны быть предсказуемыми, а поведение — стабильным даже при росте трафика.

Простая модель, на которой держится веб

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

• Индексы: ускоряют поиск, когда вы фильтруете, сортируете или соединяете таблицы. Без них база «честно» просматривает много строк и начинает тормозить.
• Транзакции: позволяют делать несколько изменений как одно целое — либо всё применилось, либо ничего. Это критично для заказов, платежей, балансов, бронирований.
• Ограничения и типы данных: помогают не превращать базу в «свалку строк» и ловить ошибки раньше.
• Схема: заранее описанная структура делает поведение системы более прогнозируемым.

Движок хранения: почему это важно

MySQL исторически известен тем, что под одной «обложкой» можно выбирать движок таблиц.

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

InnoDB сегодня — стандарт по умолчанию: транзакции, блокировки на уровне строк (меньше взаимных ожиданий при параллельной записи), восстановление после падений. Если у вас типичное приложение с активными изменениями данных — почти всегда выбирают InnoDB.

Буферы и кэши: память часто важнее «железа»

Большая часть ускорения в MySQL достигается тем, что часто используемые данные и индексы держатся в памяти. Когда нужные страницы уже в буфере, запросы выполняются заметно быстрее; когда нет — начинается ожидание диска. Поэтому настройка объёма памяти под кэш и аккуратная работа с индексами часто дают больше, чем просто «добавить CPU».

Где MySQL подходит лучше всего

MySQL отлично чувствует себя в типичных CRUD‑нагрузках: профили пользователей, каталоги, заказы, статусы, админки, где много коротких операций чтения/записи. Главное — держать запросы и индексы в порядке и не пытаться решать одной таблицей задачи аналитики, для которых лучше подходят отдельные инструменты.

InnoDB: двигатель, который сделал масштабирование реальным

Если MySQL ассоциируется с «просто хранить данные», то InnoDB превращает хранение в предсказуемую работу под нагрузкой. Именно этот движок дал MySQL свойства, без которых сложно расти: транзакции, устойчивость к сбоям и управляемую конкуренцию.

Что именно принёс InnoDB

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

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

MVCC (многоверсионность) помогает чтениям не мешать записям: читатели получают согласованный «снимок» данных, пока параллельно идут изменения. Это особенно заметно в типичных сценариях веба, где чтений больше, чем записей.

Восстановление после сбоя основано на журналировании: при перезапуске InnoDB может корректно «докрутить» незавершённые операции или откатить их, не оставляя полупринятых изменений.

Индексы B‑Tree: ускоряют чтение, но имеют цену

B‑Tree индексы ускоряют поиск по условиям (WHERE) и сортировки (ORDER BY), потому что позволяют не просматривать всю таблицу.

Но за быстрые чтения платят записи: каждый INSERT/UPDATE должен обновить и данные, и все затронутые индексы. Чем больше индексов «на всякий случай», тем медленнее запись и тем выше конкуренция.

Транзакции и уровни изоляции: баланс корректности и скорости

Уровень изоляции определяет, что именно увидит параллельное чтение, пока кто-то пишет. Чем выше изоляция, тем меньше аномалий, но тем больше накладные расходы и вероятность ожиданий. В продакшене важно выбирать уровень под задачу, а не «самый строгий по умолчанию».

Практические правила

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

Репликация MySQL: базовый кирпич роста нагрузки

Репликация в MySQL — это способ держать несколько копий одних и тех же данных на разных серверах и воспроизводить изменения в нужном порядке. На практике она решает две задачи: разгрузить чтение (read scaling) и повысить отказоустойчивость, чтобы сбой одного узла не превращался в остановку сервиса.

Зачем она нужна: чтение и «план Б»

Самый частый сценарий — записи идут в один основной сервер, а чтение распределяется по репликам. Например, профиль пользователя и оформление заказа читаются с реплики, а оплата и изменение корзины пишутся на primary.

Вторая задача — быстрый выход из аварии. Когда primary недоступен, одну из реплик можно повысить до нового primary и продолжить работу. Это не магия, а заранее выстроенный процесс, который нужно регулярно проверять.

Асинхронная и полусинхронная: где живёт риск

Асинхронная репликация быстрее и проще: primary подтверждает транзакцию клиенту, не дожидаясь реплик. Минус — при внезапной потере primary часть последних изменений может не успеть попасть на реплики.

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

Роли узлов и схемы чтения/записи

Обычно используют модель primary/replica:

• primary — единственная точка записи;
• replica — копии для чтения, аналитики, отчётов, фоновых задач.

Важно заранее решить, какие запросы имеют право идти на реплики. Классическая ошибка — отправлять на реплику чтение «сразу после записи» и ловить несогласованность из‑за лага.

Практики, которые спасают в продакшене

Главные враги — задержка реплики, дрейф данных и неотработанное переключение при сбое.

Лаг нужно измерять и учитывать на уровне приложения: критичные чтения направлять на primary или использовать механики «read-your-writes». Дрейф (когда данные на реплике отличаются) чаще всего появляется из‑за ручных правок, нестабильных запросов или разных настроек — лечится запретом прямых изменений на репликах и регулярными проверками.

Переключение (failover) должно быть описанным сценарием: кто принимает решение, как выбирается кандидат, как меняется конфигурация приложений и как предотвращается split‑brain. Если вы делаете это впервые во время инцидента — вы уже опоздали. Подробный чек‑лист удобно держать рядом с разделом /runbooks.

Шардинг: как MySQL переживает «слишком большие таблицы»

Шардинг — это разбиение данных одной логической таблицы (или набора таблиц) на несколько независимых баз/серверов (шардов), чтобы снизить нагрузку на один узел и убрать «потолок» по размеру и I/O.

К нему обычно приходят, когда вертикальное масштабирование уже не спасает: таблицы растут до десятков/сотен миллионов строк, индексы перестают помещаться в память, бэкапы и ALTER становятся слишком долгими, а один сервер упирается в диски или CPU.

Стратегии разбиения: как выбрать ключ

Главный принцип: запросы должны чаще попадать в один шард, а не «веером» во все.

• По пользователю (user_id / tenant_id): популярный вариант для сервисов с ярко выраженной «владельческой» моделью данных. Хорошо работает, если большинство операций — внутри одного пользователя.
• По времени (дата/месяц): удобно для событий, логов, заказов, метрик. Старые партиции/шарды проще архивировать и дешевле хранить.
• По географии (регион/страна/ДЦ): помогает снижать задержки и изолировать регионы. Часто комбинируют с репликацией внутри региона.

Важно заранее продумать, что будет, когда один шард «перерастёт» остальные: нужен план ребалансинга и понятная схема вычисления shard key.

Маршрутизация запросов: приложение или прокси

Есть два распространённых подхода:

• На уровне приложения: код знает, как по ключу выбрать шард. Плюс — максимальный контроль и предсказуемость. Минус — логика шардинга расползается по сервисам.
• Через прокси/прослойку: отдельный компонент принимает запросы и маршрутизирует их (иногда ещё и балансирует чтения/записи). Удобно централизовать правила, но добавляет ещё один слой, который надо мониторить и масштабировать.

Цена шардинга: за масштаб платят сложностью

Шардинг почти всегда усложняет:

• JOIN’ы: джоины между шардами либо запрещают, либо делают через денормализацию/агрегации.
• Транзакции: атомарные операции между шардами — боль; двухфазный коммит и распределённые блокировки редко оправданы. Чаще переходят к «сагам» и идемпотентности.
• Миграции и перенос данных: перенос части ключей на новый шард требует инструментов, двойной записи или «теневого» чтения, а также аккуратной синхронизации.

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

Производительность запросов: что реально ускоряет MySQL

Ускорение MySQL почти всегда начинается не с «магических настроек», а с понимания того, как сервер выполняет конкретный запрос: какие таблицы читает, в каком порядке, сколько строк просматривает и где тратит время.

Как читать EXPLAIN без теории

EXPLAIN (и особенно EXPLAIN ANALYZE в новых версиях) помогает увидеть три практичных вещи:

• Порядок доступа: какая таблица идёт первой, как строится соединение, нет ли «случайного» полного сканирования.
• Использование индекса: используется ли нужный индекс и насколько он подходит (например, по префиксу составного индекса).
• Оценка объёмов: сколько строк планировщик ожидает прочитать и насколько это похоже на реальность. Если «ожидает 10 строк», а по факту тысячи — оптимизация часто начинается со статистики и индексов.

Типичные проблемы, которые тормозят сильнее всего

N+1: приложение делает один запрос за списком сущностей и затем по одному запросу на каждую сущность. Лечится джойнами, пакетными выборками (IN (...)), предварительной загрузкой.

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

Сортировки на диске: Using filesort и/или Using temporary в плане — сигнал проверить ORDER BY, GROUP BY и наличие индекса, который поддерживает нужный порядок.

Паттерны оптимизации, которые работают в продакшене

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

Ограничивайте выборки: не тащите лишние столбцы, ставьте разумный LIMIT, используйте пагинацию. Для больших списков обычно стабильнее keyset‑пагинация (по последнему id/created_at), чем глубокий OFFSET.

Когда помогает переписывание схемы

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

Надёжность и HA: как избежать простоя и потери данных

Высокая доступность (HA) для MySQL — это не «магия без падений», а набор договорённостей и механизмов, которые ограничивают два параметра.

RPO и RTO простыми словами

RPO (Recovery Point Objective) — сколько данных вы готовы потерять при аварии. Если RPO = 0, то потеря транзакций недопустима; если RPO = 5 минут, то допустимо откатиться на последние 5 минут.

RTO (Recovery Time Objective) — как быстро сервис должен вернуться в строй. RTO = 30 секунд означает автоматическое переключение и быстрый прогрев, RTO = 30 минут допускает более «ручную» процедуру.

Важно заранее зафиксировать RPO/RTO для каждого сервиса: у корзины покупок и у аналитики обычно разные требования.

Автофейловер и риск split‑brain

Автофейловер ускоряет восстановление, но добавляет риск split‑brain: когда два узла одновременно считают себя «главными» и принимают запись, а потом данные расходятся.

Минимизируют это комбинацией мер:

• внешний «арбитр»/кворум (чтобы решение о переключении принималось не одним узлом);
• запрет записи на старом мастере при потере связи (fencing, отключение VIP/доступа);
• короткие и понятные таймауты, чтобы избежать «дёрганых» переключений;
• тесты фейловера в рабочеподобной среде, а не только «на бумаге».

Бэкапы: логические vs физические и проверка восстановления

Логические бэкапы (дампы) удобны для выборочного восстановления и миграций, но медленнее и тяжелее на больших объёмах.

Физические (снимки файлов/страниц) быстрее и чаще подходят для крупных баз, но требуют аккуратности с согласованностью.

Ключевой пункт — не «делать бэкап», а регулярно проверять восстановление: поднимать копию, прогонять базовые запросы, сверять контрольные показатели.

План аварийного восстановления (DR): кто и что делает

Хороший DR‑план — короткий чек‑лист с ролями и порядком действий:

1. Кто объявляет инцидент и фиксирует время начала.
2. Кто переводит систему в режим «только чтение»/останавливает запись.
3. Кто выполняет переключение/восстановление и как проверяет целостность.
4. Кто возвращает трафик и подтверждает, что метрики нормализовались.
5. Кто делает постмортем и обновляет инструкции.

Если этот план не репетировали, его, по сути, нет.

Эксплуатация в продакшене: мониторинг, лимиты и рутина

MySQL обычно «ломается» не внезапно, а через мелкие симптомы: растёт время ответа, накапливаются блокировки, репликация начинает отставать. Поэтому продакшен — это не только настройки, но и дисциплина наблюдаемости и обслуживания.

Наблюдаемость: какие метрики действительно помогают

Смотрите не на «CPU 20%», а на метрики, которые объясняют пользовательскую задержку:

• Латентность запросов: p95/p99 по типам запросов (чтение/запись), отдельно для самых частых эндпоинтов.
• Блокировки и конкуренция: время ожидания блокировок, количество конфликтов, длинные транзакции (часто главный источник «подвисаний»).
• I/O и буферный пул: нагрузка на диск, задержки чтения/записи, cache hit ratio InnoDB, объём грязных страниц и скорость их сброса.
• Репликация: lag (секунды отставания), состояние потоков репликации, частота реконнектов, ошибки SQL/IO потоков.

Важно заранее договориться о порогах: например, p99 вырос в 2 раза или lag > N секунд — это инцидент, а не «понаблюдаем».

Логи и трассировка: что открывать при деградации

При ухудшении производительности полезнее всего связка:

• slow query log (с корректным порогом) + выборка самых «тяжёлых» запросов;
• performance_schema для ожиданий (I/O, блокировки, mutex) и топа запросов по времени;
• error log для признаков проблем с диском, рестартов, падений репликации.

Если в приложении есть распределённая трассировка, привязывайте спаны к конкретным SQL‑запросам: так быстрее видно, что «медленно» — сеть, пул соединений или сама база.

Планирование роста: диски, IOPS, память и сеть

Ёмкость диска — только половина истории. Планируйте запас по:

• IOPS и latency (особенно для fsync при записи);
• RAM под буферный пул и рабочие наборы индексов;
• сети (репликация, бэкапы, сервисные операции).

Отдельно учитывайте «всплески»: ночные джобы, массовые импорты, отчёты. Часто именно они определяют нужный запас.

Регламент обслуживания: чтобы база не старела

Рутина, которая экономит время на инцидентах:

• регулярные обновления MySQL и ОС с проверкой совместимости;
• контроль «поплывших» индексов и своевременная реиндексация там, где это оправдано;
• чистка исторических данных (архивация/TTL/партиционирование) — иначе рост таблиц незаметно съедает I/O и время бэкапов;
• периодическая проверка восстановления из бэкапа на тестовом стенде.

Продакшен‑эксплуатация MySQL — это набор простых практик. Но именно они превращают базу из «работает пока повезёт» в предсказуемый сервис с понятными лимитами.

Миграции без боли: как менять схему и данные на ходу

Миграции в MySQL — это не «одна команда ALTER и готово», а управляемый процесс. В продакшене важнее всего предсказуемость: вы заранее знаете, сколько займёт операция, какие риски, и как быстро вернуться назад.

Безопасные миграции схемы: обратимость и поэтапность

Хорошая миграция почти всегда обратима. Если добавляете столбец — подумайте, как его удалить; если меняете тип — как сохранить исходные значения. Практика: сначала делайте изменения, которые не ломают старый код (например, добавить новый nullable‑столбец), потом выкатывайте приложение, и только затем — «затягивайте гайки» (NOT NULL, удаление старых полей).

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

Онлайн‑изменения таблиц: когда нужны инструменты

InnoDB в современных версиях MySQL поддерживает много вариантов online DDL, но не все. Некоторые изменения всё ещё могут долго держать блокировки или создавать пиковую нагрузку.

Когда таблица большая и ошибка дорого стоит, используют специализированные инструменты:

• pt-online-schema-change (Percona) — создаёт «теневую» таблицу, копирует данные, поддерживает триггерами актуальность.
• gh-ost (GitHub) — похожий подход, но с упором на контроль нагрузки и минимизацию влияния.

Смысл один: изменить схему так, чтобы приложение почти не почувствовало остановки.

Миграции данных между кластерами

Для переноса данных чаще всего комбинируют:

• дамп/восстановление (логично для небольших объёмов или как стартовая точка);
• репликацию (чтобы догнать «живые» изменения после заливки);
• «двусторонний период» на уровне приложения (dual-write или синхронизация), если нужен плавный переход без жёсткого стопа.

Ключевой момент — спланировать момент переключения (cutover): кто становится источником истины и как убедиться, что хвост репликации нулевой.

Чек‑лист перед релизом

Перед запуском миграции:

1. Прогоните её на копии продакшена (или на близком по объёму стенде) и измерьте время.
2. Проверьте влияние на индексы и типичные запросы (EXPLAIN, профилирование).
3. Подготовьте план отката: что делаем, если операция зависла, выросла задержка, появились ошибки.
4. Назначьте ответственных и метрики для контроля (время выполнения, блокировки, lag репликации).

Так миграции превращаются из «ночного приключения» в рутинную, управляемую процедуру.

Почему MySQL остаётся актуальным рядом с новыми решениями

Новые базы обещают «проще и быстрее», но MySQL всё ещё часто оказывается самым прагматичным выбором. Причина не в привычке, а в предсказуемости поведения, зрелой экосистеме и понятной экономике владения — особенно когда продукт растёт постепенно, а не скачком.

Когда MySQL выигрывает

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

Если вам нужны транзакции, консистентность и ясные гарантии (ACID), InnoDB даёт надёжную основу. Плюс важна стоимость: MySQL легко хостится почти везде, имеет массу инструментов, а найти специалистов обычно проще, чем под нишевую СУБД.

Отдельный практичный плюс — «предсказуемое ухудшение»: при росте данных и RPS проблемы чаще решаются измерениями, индексами, кешированием и распределением нагрузки, а не переписыванием всей платформы.

Когда лучше рассмотреть альтернативы

Есть классы задач, где MySQL будет не лучшим инструментом:

• Аналитика и тяжёлые агрегаты на больших объёмах (витрины, отчёты, BI) — чаще выигрывают колоночные хранилища.
• Поиск по тексту и релевантность (морфология, ранжирование, подсветка) — лучше выделенный поисковый движок.
• Графовые связи (много «переходов» по отношениям, рекомендации, социальные графы) — проще и быстрее в графовых БД.

Важно: это не «MySQL плох», а «не тот ключ к замку».

Архитектура «поли‑БД» как норма

В зрелых системах редко обходятся одной базой. Частая формула: MySQL как источник истины + кеш для горячих чтений + очередь для асинхронной обработки + аналитическое хранилище для отчётности. Такой подход уменьшает требования к MySQL и снижает риск, что один тип запросов «съест» ресурсы у остальных.

Критерии выбора: не только скорость

Выбирайте по совокупности факторов:

• компетенции команды и скорость найма;
• требования SLA и допустимый простой;
• сложность сопровождения (бэкапы, обновления, мониторинг, миграции);
• прогноз роста данных и «стоимость ошибки» при смене технологии.

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

Как TakProsto.AI помогает быстрее пройти путь от идеи до продакшена

Когда речь заходит о масштабировании MySQL, большинство проблем упирается не в «особые настройки», а в скорость инженерного цикла: правильно сформулировать требования (RPO/RTO), спроектировать схему, зафиксировать правила миграций, собрать наблюдаемость и оформить runbooks.

TakProsto.AI (vibe‑coding платформа для российского рынка) помогает ускорить именно этот цикл: вы описываете приложение и требования в чате, а система помогает собрать веб‑интерфейс на React, бэкенд на Go и базу на PostgreSQL. Даже если в вашем проекте MySQL остаётся основной СУБД, TakProsto.AI удобно использовать для:

• быстрого прототипирования админок/внутренних сервисов вокруг данных (инструменты поддержки, кабинеты, панели);
• подготовки «скелета» миграций, чек‑листов релиза и runbooks под вашу архитектуру;
• сборки отдельного контура (например, сервис отчётности или фоновые воркеры) с понятным деплоем, снапшотами и откатом.

Практический бонус: на платформе есть экспорт исходников, хостинг/деплой, кастомные домены, а также режим планирования, чтобы заранее разложить изменения по шагам. Для команд, которым важно размещение в РФ и работа с локализованными/opensource LLM‑моделями, это снижает трение в процессах и ускоряет выпуск изменений.

Пошаговый план масштабирования: от малого к большому

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

1) Оцените текущие узкие места (прежде чем что-то менять)

Начните с короткой диагностики по четырём направлениям — так вы поймёте, где реально теряется время и деньги.

• Запросы: топ медленных запросов (по времени и по частоте), наличие full scan, сортировок на диске, «раздувшихся» JOIN.
• Схема: недостающие/лишние индексы, слишком широкие таблицы, хранение «всего в одной таблице», неконтролируемый рост исторических данных.
• Ресурсы: CPU (однопоточные пики), память (давление на буферный пул), диски (IOPS/latency), сеть.
• Архитектура приложения: N+1 запросы, отсутствие кеша, длинные транзакции, смешение тяжёлой аналитики и OLTP в одной базе.

Если у вас нет метрик, любые изменения будут похожи на угадывание. Зафиксируйте базовую точку: p95/p99 времени ответа, QPS, lag репликации (если есть), объём данных и темпы роста.

2) Порядок действий: от простого к сложному

Самый безопасный и предсказуемый порядок обычно такой:

1. Индексы и запросы. Оптимизируйте 10–20 самых дорогих запросов, проверьте планы выполнения, уберите лишние поля из SELECT, добавьте нужные составные индексы, сократите время транзакций.
2. Разделение чтения и записи через репликацию. Вынесите чтение на реплики, разгрузите мастер, подготовьтесь к отказоустойчивости (переключение, проверки целостности).
3. Шардинг и/или разделение сервисов. Переходите сюда, когда упёрлись в пределы вертикального роста и оптимизации, а модель данных и трафик стабильно предсказуемы.

Репликация часто даёт «второе дыхание» без ломки модели данных, а шардинг почти всегда повышает стоимость разработки и поддержки.

3) Типовые ошибки, которые замедляют рост

• Преждевременный шардинг: усложнение без измеримой выгоды, рост числа «распределённых» багов и операционных сценариев.
• Игнорирование бэкапов и восстановления: бэкап без регулярного restore‑теста — это надежда, а не план.
• Отсутствие тестов и стенда, похожего на прод: миграции и новые индексы выкатываются «вслепую», получаете неожиданные блокировки и регрессии.

4) Чек‑лист на ближайший спринт (5–10 задач)

1. Включить сбор медленных запросов и сформировать топ‑20 по суммарному времени.
2. Для топ‑5 запросов: проверить EXPLAIN, добавить/исправить индексы, убрать лишние JOIN/сортировки.
3. Проверить и сократить «длинные» транзакции в приложении (таймауты, ретраи, порядок операций).
4. Настроить регулярные бэкапы и еженедельный тест восстановления на отдельном окружении.
5. Ввести мониторинг ключевых метрик: p95/p99, QPS, CPU, IO latency, buffer pool hit rate, рост таблиц.
6. Выделить тяжёлые отчёты/выгрузки в отдельный контур (реплика, отдельная база или очередь задач).
7. Подготовить план репликации/фейловера: кто переключает, как проверяем целостность, как возвращаемся назад.
8. Договориться о правилах миграций: небольшие изменения, обратимость, прогон на стейджинге, окна риска.

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