Параметры БД надо крутить не «на глаз», а по симптомам и метрикам

Параметры БД надо крутить не «на глаз», а по симптомам и метрикам

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

Рабочий порядок простой:
— сначала снимите базовую картину: CPU, I/O, cache hit, locks, temp usage;
— меняйте один параметр за раз, иначе не поймете, что сработало;
— фиксируйте до/после: план, время ответа, число чтений, рост памяти;
— проверяйте побочные эффекты: больше памяти одному воркеру — меньше остается остальным.

Частая ошибка — лечить очередь запросов увеличением всех буферов подряд. Это не настройка, а попытка заткнуть дыру одеялом. Если упираетесь в диск, ищите плохие планы, лишние чтения и сортировки, а не просто раздувайте кэш. Схема простая, но дьявол кроется в статистике.

Если параметр нужен только «на всякий случай», его место в черновике, а не в production. Сначала мониторинг, потом индексы и уже потом конфиг.