Почему база падает не от запросов, а от соединений

Когда на backend внезапно приходит много пользователей, первое подозрение обычно падает на тяжёлые SQL-запросы. Но часто причина проще: приложение создаёт слишком много соединений с MySQL. Каждый HTTP-запрос открывает новый коннект, выполняет короткую операцию и закрывает его. При небольшом трафике это почти незаметно. При всплеске сервер быстро упирается в max_connections, RAM и системные лимиты.

Connection pool решает эту задачу не ускорением SQL как такового, а управлением доступом к базе. Вместо бесконтрольного создания соединений приложение держит ограниченный набор открытых коннектов и переиспользует их между запросами. Это снижает накладные расходы, защищает MySQL от шторма подключений и делает поведение backend предсказуемее.

Для асинхронных Python-сервисов тема особенно важна. Event loop позволяет обслуживать много запросов, но база данных не обязана выдерживать такое же число параллельных соединений.

Почему нельзя просто поднять max_connections

Увеличение max_connections выглядит быстрым решением, но часто только откладывает аварию. Каждое соединение потребляет память на стороне MySQL и ресурсы ОС. Если разрешить тысячи соединений, можно получить не более высокую пропускную способность, а более тяжёлую деградацию.

Кроме того, большое количество одновременных запросов усиливает конкуренцию за locks, buffer pool, disk I/O и CPU. База начинает отвечать медленнее, запросы висят дольше, соединения освобождаются позже, очередь растёт ещё сильнее.

Пул соединений вводит backpressure. Если свободных соединений нет, запрос ждёт, получает controlled timeout или быстрый отказ. Это неприятно для части пользователей, но лучше, чем положить всю базу.

Как устроен пул

Минимальный пул хранит набор соединений и выдаёт их задачам по запросу. После выполнения SQL соединение возвращается в пул. В асинхронной реализации ожидание свободного соединения не блокирует поток, а отдаёт управление event loop.

Полезные параметры:

min_size — сколько соединений держать заранее;
max_size — верхний предел активных соединений;
acquire timeout — сколько ждать свободный коннект;
idle timeout — когда закрывать неиспользуемые соединения;
max lifetime — когда пересоздавать старое соединение;
health check — как проверять, что коннект жив;
queue limit — сколько запросов может ждать пул.

Без queue limit пул может перенести проблему из MySQL в память приложения: тысячи корутин будут ждать соединение и удерживать контекст запроса.

Размер пула — это инженерный лимит

Размер пула нельзя выбирать по формуле «чем больше, тем лучше». Он должен соответствовать возможностям базы и профилю запросов. Если MySQL стабильно обрабатывает 50 параллельных операций, пул на 500 соединений не ускорит систему.

Практичный подход:

измерить среднее и p95 время SQL-операций;
понять целевую пропускную способность;
задать небольшой пул;
нагрузочно проверить latency;
увеличивать размер до точки, где база начинает деградировать;
оставить запас и настроить алерты.

Для нескольких инстансов приложения нужно считать общий лимит. Если десять pod’ов имеют пул по 50 соединений, MySQL увидит до 500 соединений. Это частая ошибка при масштабировании в Kubernetes.

Таймауты важнее красивого API

Пул без таймаутов опасен. Если база замедлилась, запросы начинают бесконечно ждать соединение или ответ SQL. Снаружи это выглядит как зависший сервис.

Нужны минимум три уровня таймаутов:

ожидание соединения из пула;
выполнение SQL-запроса;
общий timeout HTTP-запроса или фоновой задачи.

Если timeout acquire сработал, приложение может вернуть 503, применить retry позже или деградировать функциональность. Важно, чтобы это было явное поведение, а не случайное зависание.

Транзакции и возврат соединения

Главная эксплуатационная ошибка — вернуть соединение в пул в грязном состоянии. Например, транзакция не завершена, session variable изменена, временная таблица осталась, isolation level поменялся. Следующий запрос получает тот же коннект и наследует чужой контекст.

Поэтому пул должен гарантировать cleanup:

rollback незавершённой транзакции;
сброс session state;
закрытие курсоров;
обработку исключений;
удаление сломанного соединения из пула.

В коде полезно использовать context manager: соединение выдаётся на время блока и автоматически возвращается или закрывается при ошибке.

Что мониторить

Connection pool должен быть видимым в метриках. Минимальный набор:

активные соединения;
свободные соединения;
размер очереди ожидания;
время ожидания acquire;
количество timeout’ов;
количество пересозданных соединений;
SQL latency;
ошибки MySQL;
общее число соединений на стороне базы.

Особенно полезен график acquire latency. Если он растёт, приложение уже испытывает давление, даже если MySQL ещё отвечает. Это ранний сигнал, что нужно смотреть на запросы, размер пула или нагрузку.

Пул не заменяет оптимизацию SQL

Важно не использовать pool как способ спрятать медленные запросы. Если один запрос держит соединение 10 секунд, он блокирует ресурс пула. При нескольких таких запросах очередь быстро вырастет.

Нужно отдельно работать с индексами, планами выполнения, пагинацией, batch-размером и блокировками. Пул защищает базу от лишних соединений, но не делает плохие запросы хорошими.

Для read-heavy сценариев можно добавить read replicas, кеширование или materialized views. Для write-heavy — очередь, batching или изменение модели данных. Пул остаётся базовым ограничителем, а не универсальным ускорителем.

Практический вывод

Асинхронный backend способен создать гораздо больше параллелизма, чем база может безопасно обработать. Поэтому connection pool — обязательный элемент архитектуры, а не оптимизация на потом.

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