[Главная](https://hmbastion.com/ru/) [Блог](https://hmbastion.com/ru/blog/) Инфраструктура Инфраструктура 5 мин чтения # Подберите размер базы данных SQL с учётом её рабочего набора и дорогих запросов Подбор размера базы данных — это больше, чем сравнение размера каталога данных с RAM сервера. Небольшая база данных может работать плохо из-за повторяющихся сканирований или конкуренции за блокировки, а более крупная может эффективно обслуживать сфокусированную нагрузку. Исследуйте работу, которую приложение поручает базе данных, прежде чем выбирать следующее распределение ресурсов. Редакция HM Bastion Опубликовано 2026-10-26 ## В этом руководстве - [Опишите нагрузку до выбора размера](https://hmbastion.com/ru/blog/sql-database-sizing-query-bottlenecks/#describe-the-work-and-data) - [Найдите запрос, который потребляет полезное время](https://hmbastion.com/ru/blog/sql-database-sizing-query-bottlenecks/#find-the-query-that-matters) - [Меняйте по одной причине за раз](https://hmbastion.com/ru/blog/sql-database-sizing-query-bottlenecks/#choose-a-reversible-change) - [Проверяйте при конкурентной нагрузке и сохраняйте восстановление в плане](https://hmbastion.com/ru/blog/sql-database-sizing-query-bottlenecks/#test-growth-and-recovery) [Все руководства по хостингу](https://hmbastion.com/ru/blog/) ## Практический вывод Выявляйте дорогие и повторяющиеся запросы, безопасно изучайте их планы, измеряйте память и параллелизм вместе и изменяйте тот запрос или ресурс, который действительно ограничивает полезную работу. ## Опишите нагрузку до выбора размера Перечислите движок базы данных, приложение, основные таблицы и важные пользовательские сценарии. Задание отчётности, сканирующее исторические данные, ведёт себя иначе, чем небольшой поиск за каждым веб-запросом. Зафиксируйте обычный объём запросов, параллельные задания, рост данных и операции, чувствительные ко времени. Включите фоновые задачи, импорт и экспорт: они могут создавать самые загруженные периоды, даже когда публичный трафик низок. Не включайте учётные данные и персональные данные в заметки о подборе размера, которыми делитесь. Оценивайте хранилище сверх текущих данных таблиц. Индексы, журналы транзакций, временная работа, рост и обслуживание — всё это может требовать места. Резервные копии также требуют продуманного места назначения и процедуры восстановления. Цифра хранилища на карточке хостинга — это ёмкость, выделенная сервису, а не утверждение, что каждый байт должен быть занят живой базой данных. Следите за тенденциями свободного места и оставляйте запас для операций, которые действительно выполняют ваш движок и приложение. Рабочий набор — это данные и индексы, к которым нагрузка обращается повторно. Он может быть намного меньше полной исторической базы данных и может меняться, когда отчёт или акция становятся популярными. Память помогает, когда полезные страницы можно повторно использовать, но общее правило, что все данные должны помещаться в RAM, слишком грубое. Наблюдайте чтения, поведение кэша и длительность запросов во время репрезентативной работы, а не применяйте универсальный процент памяти. ## Найдите запрос, который потребляет полезное время Начните с медленного пути выполнения приложения и свяжите его с активностью базы данных. Один исключительно медленный запрос заметен, но скромный запрос, повторяемый сотни раз, может потреблять больше суммарной работы. Группируйте похожие запросы и сравнивайте частоту, длительность, просмотренные или возвращённые строки, а также периоды, когда пользователи замечают задержку. Используйте средства журналирования и диагностики, доступные для вашего движка, с надлежащим доступом и хранением потенциально чувствительных данных запросов. План выполнения описывает, как движок предполагает извлекать и объединять данные. Читайте путь доступа, оценочное число строк, соединения и работу по сортировке вместе. Сканирование не является автоматически ошибкой: для небольшой таблицы или широкого запроса оно может быть разумным. Вопрос в том, соответствует ли работа результату, который нужно получить приложению. Сравнивайте оценочное и наблюдаемое поведение, когда доступны подходящие инструменты, и фиксируйте точную схему и версию движка. | Симптом | Возможная причина | Какие данные собрать | | --- | --- | --- | | Много обработанных строк при малом результате | Форма запроса или отсутствие полезного индекса | План, предикаты и просмотренные строки | | Задержка растёт при одновременных записях | Конкуренция за блокировки или транзакции | Ожидающие транзакции и длительность транзакций | | Повторяющиеся идентичные выборки | Повторение запросов в приложении | Сгруппированная частота запросов и трассировка запросов | | Медленные большие сортировки или отчёты | Рабочие данные превышают доступную память | Временная работа, давление на память и размер отчёта | Будьте осторожны с инструментами, которые выполняют инструкцию во время её измерения. PostgreSQL EXPLAIN ANALYZE запускает запрос, а инструкции, изменяющие данные, могут изменить данные, если расследование намеренно не предотвращает такой исход. Функции анализа MySQL также требуют понимания выбранной инструкции и версии. По возможности используйте репрезентативную тестовую среду. Никогда не вставляйте незнакомую диагностическую команду в продакшен только потому, что в ней есть слово explain. ## Меняйте по одной причине за раз Индекс может сократить число строк, необходимых для полезной выборки, но он также занимает хранилище и добавляет работу по обслуживанию при записи. Проектируйте его вокруг фактических предикатов и порядка, затем измеряйте соответствующие чтения и записи. Создание индексов по каждому столбцу создаёт затраты без доказанной пользы. Крупные операции со схемой требуют собственного плана, поскольку блокировки, временное пространство и время завершения зависят от движка, операции и рабочей нагрузки. Изменения в приложении могут устранить работу до того, как она дойдёт до базы данных. Выбирайте только нужные столбцы, избегайте повторного получения одной и той же связи и используйте продуманную стратегию постраничного вывода для больших списков. Держите транзакции сфокусированными, чтобы они не удерживали ресурсы в ожидании несвязанных сетевых вызовов. Эти решения часто улучшают как средний запрос, так и худшие периоды конкуренции. Проверяйте результат, возвращаемый пользователям, а также сокращённую длительность запроса. Увеличивайте ресурсы, когда это подтверждают данные. Больше RAM может помочь полезному рабочему набору, а дополнительные CPU могут помочь работе, которая действительно может выполняться параллельно. Ни одно из изменений автоматически не устраняет долго удерживаемую блокировку или ненужное полное сканирование. При выборе хостинга сравнивайте точное распределение памяти, хранилища и процессора, затем учитывайте операционную систему и другие службы, разделяющие машину. Задокументируйте, почему это распределение соответствует измеренной рабочей нагрузке. ## Проверяйте при конкурентной нагрузке и сохраняйте восстановление в плане - Сохраняйте схему, версию движка и базовые измерения. - Используйте репрезентативные распределения данных, а не только крошечные образцы таблиц. - Сравнивайте тот же запрос и рабочую нагрузку после одного контролируемого изменения. - Измеряйте успешные операции, задержку и ошибки при конкурентной работе. - Проверяйте резервные копии и процедуру восстановления перед рискованным обслуживанием. Тест с одним соединением не описывает каждый пик продакшена. Повторите соответствующую рабочую нагрузку с реалистичными конкурентными запросами и запланированными задачами и остановитесь при достижении согласованных пределов ошибок или ресурсов. Используйте синтетические или надлежащим образом защищённые тестовые данные. Не вовлекайте внешний платёжный сервис или системы другой стороны в сгенерированную рабочую нагрузку без организации такого участия. Держите генератор нагрузки достаточно отдельно, чтобы были видны его собственные ограничения. Наконец, превратите диагностику в краткую запись об обслуживании. Сохраняйте отпечаток запроса, план, наблюдаемое ограничение, выбранное изменение и путь отката. Добавьте рост хранилища и требования к восстановлению к следующей дате проверки. Это даёт будущим сопровождающим обоснованную отправную точку при изменении рабочей нагрузки вместо загадочной настройки памяти или индекса, который все боятся трогать. Примеры продуктов используют опубликованный каталог HM Bastion. Доступность, цены и доступные опции отображаются при настройке заказа. ## Выберите следующий фундамент. [Сравнить ресурсы VPS](https://hmbastion.com/ru/hosting/?category=cloud) [Прочитать руководство по ресурсам сервера](https://hmbastion.com/ru/blog/understand-server-resources/) [Обсудить рабочую нагрузку базы данных](https://hmbastion.com/ru/support/) ## Источники и дополнительное чтение - [Документация MySQL: оптимизация запросов с EXPLAIN](https://dev.mysql.com/doc/refman/8.4/en/using-explain.html) - [Документация PostgreSQL: безопасное использование EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html) - [Документация MySQL: буферный пул InnoDB](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool.html) ## Продолжить изучение [ Безопасность 5 мин чтения ## Обеспечьте работу HTTPS на протяжении всего жизненного цикла сертификата Спланируйте проверку домена, продление сертификата, развёртывание и внешние проверки, чтобы HTTPS оставался корректным после первой успешной установки. ](https://hmbastion.com/ru/blog/https-tls-certificate-lifecycle/) [ Инфраструктура 5 мин чтения ## IPv4, IPv6 и межсетевые экраны: проверьте пути к вашему серверу Проведите инвентаризацию прослушиваемых сервисов, публичных адресов и политик межсетевого экрана в обоих семействах IP перед публикацией приложения или изменением сетевого доступа. ](https://hmbastion.com/ru/blog/ipv4-ipv6-firewall-exposure/)