Параметры БД: как не ускорить одно и не положить всё остальное

Параметры БД: как не ускорить одно и не положить всё остальное

Коллеги, давайте разберем план выполнения: конфигурация БД — это не «поставил побольше памяти и всё полетело». Каждый параметр влияет на CPU, I/O, блокировки и предсказуемость нагрузки. Ошибка типовая: тюнят одну метрику, а потом удивляются росту latency в соседних запросах.

Рабочий порядок такой:
— сначала фиксируем узкое место: CPU, диск, память, конкуренция;
— потом смотрим, что можно менять без рестарта и какой у этого оверхед;
— отдельно проверяем, как параметр ведет себя под пиковыми запросами, а не в тишине;
— любые изменения делаем по одному, с замером до и после.

Самые опасные настройки — буферы, лимиты параллелизма, параметры сортировок и кэшей. Если их задрать без расчета, БД начинает конкурировать сама с собой: больше параллельных сессий, больше памяти, больше swap, и вот уже «ускорение» превращается в очередь на I/O. Золотое правило: сначала мониторинг, потом индексы. И да, сначала тоже мониторинг.

Перед выкладкой в продакшен проверьте три вещи: хватает ли памяти при худшем сценарии, не растет ли число блокировок, не ломается ли план выполнения на реальных данных. Схема простая, но дьявол кроется в статистике: если данные распределены криво, красивый параметр может только ухудшить картину.

Меняйте конфиг как код: одна правка, один замер, один вывод. Иначе в продакшене потом будет очень сложно понять, что именно «помогло».