Что делать, если выросли базы данных до миллионов строк – масштабирование личных кабинетов

Ваш бизнес растёт. Вчера в базе было 100 заказов, сегодня — 100 тысяч, через месяц будет миллион. И тут вы замечаете, что отчёты стали грузиться по 30 секунд, а поиск по каталогу виснет. Типичная боль любого растущего проекта. Хорошая новость: Falcon Space и MS SQL Server могут работать с десятками миллионов записей, если правильно всё настроить.

В нашей практике были проекты с 12 миллионами строк в логовой таблице, с 5 миллионами товаров, с 2 миллионами заказов. Всё работало без подвисаний. Расскажу, как мы масштабируем проекты и что делать, если ваша база выросла.

Когда пора бить тревогу

Первые признаки:

• Отчёты, которые раньше открывались за 2 секунды, теперь — за 20.
• Поиск по каталогу товаров тормозит.
• Экспорт в Excel из личного кабинета вылетает по таймауту.
• Панель управления SQL Server показывает много «ожидающих» запросов.
• Размер базы перевалил за 20-30 ГБ.

Не пугайтесь. 100 тысяч строк — не предел. MS SQL Server может хранить до 524 петабайт. Ограничение не в объёме, а в скорости запросов.

Сколько записей выдерживает Falcon Space (реальные цифры)

• Таблица заказов: 1 200 000 записей — отчёты за 1-2 секунды.
• Таблица логов действий: 12 000 000 записей — выборка по дате за 3 секунды.
• Таблица товаров: 500 000 позиций — поиск за 0,5 секунды.
• CRM для автосервиса: 300 000 заказов, 2 000 000 операций — быстро.

Самый большой проект — лог-таблица с 12 млн записей (все действия пользователей за 3 года). Отчёты строились через агрегирующие процедуры. Всё работало при 2 ГБ RAM.

Шаг 1. Индексы — ваш главный инструмент

Как понять, каких индексов не хватает:

1. Запустите в SQL Server Management Studio свой медленный запрос.
2. Включите «Actual Execution Plan».
3. Если видите значок «Missing Index» — SQL Server подскажет, какой индекс добавить.

Пример: если часто ищете заказы по дате, должен быть индекс на поле created_at. Если по клиенту + дате — составной индекс (client_id, created_at).

Индексы нужны на поля, участвующие в WHERE, JOIN, ORDER BY, GROUP BY. Но не перебарщивайте — каждый индекс замедляет вставку. Оптимально 5-10 индексов на таблицу.

Шаг 2. Оптимизация запросов

• Не используйте SELECT * — указывайте только нужные колонки.
• Избегайте функций в WHERE — вместо WHERE YEAR(created_at) = 2025 пишите WHERE created_at BETWEEN '2025-01-01' AND '2025-12-31'.
• Ограничивайте количество строк в отчётах — пагинация по 50-100 строк.
• Используйте временные таблицы для сложных отчётов — сначала отберите нужные данные во временную таблицу, потом джойните.

Пример: плохой запрос: SELECT * FROM orders o JOIN clients c ON o.client_id = c.client_id JOIN order_items oi ON o.order_id = oi.order_id. Хороший запрос: сначала отбираем заказы за период во временную таблицу, затем джойним.

Шаг 3. Архивация старых данных

Если в таблице 10 млн записей, а нужны только последние 1 млн, остальные 9 млн выгружаем в архивную таблицу. Это делается скриптом раз в месяц.

Пример: в проекте архивировали логи операций старше 2 лет. Основная таблица уменьшилась с 12 млн до 2 млн записей, отчёты ускорились в 20 раз.

Шаг 4. Апгрейд сервера (если ничего не помогает)

• Добавьте RAM (с 4 до 8 ГБ). SQL Server любит память.
• Увеличьте ядра CPU (с 2 до 4).
• Перейдите с HDD на SSD (прирост — 10-20 раз).

В 90% случаев проблема решается индексами и хорошими запросами.

Реальный пример: ускорение отчёта в 100 раз

У клиента отчёт по продажам за месяц строился 2 минуты. Не было индекса по дате на таблице заказов. Добавили индекс — стало 1,2 секунды. Заменили SELECT * на SELECT нужных колонок — стало 0,4 секунды.

Клиент был счастлив.

Миллионы строк — не страшно. Страшно, когда вы не знаете, что делать. Индексы, правильные запросы, архивация и чуть-чуть апгрейда сервера — и ваш сайт будет летать.

Насколько полезной была статья?