Настройка параметров БД: не тюнинг “на глаз”, а работа по узким местам

Настройка параметров БД: не тюнинг “на глаз”, а работа по узким местам

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

Сначала смотрим, где реально узко: • чтение с диска и кэш-попадания • рост очередей на CPU • долгие транзакции и блокировки • всплески сортировок, хеша и temp-объектов. Золотое правило: сначала мониторинг, потом индексы и только потом конфиг.

Дальше меняем по одному параметру за раз и фиксируем эффект. Если сразу поднять всё подряд, вы не поймёте, что именно помогло, а что просто совпало. Важны базовые метрики до и после: latency, throughput, wait events, объем spill’ов, число deadlock’ов и давление на память.

Отдельно осторожно с памятью и параллелизмом: завышенные лимиты часто лечат один запрос и убивают весь сервер. Схема простая, но дьявол кроется в статистике: одинаковый параметр на OLTP и на тяжёлой аналитике работает по-разному.

Итог: любой тюнинг конфигурации начинайте с профиля нагрузки и узкого места, а не с чужого “рабочего набора”. В продакшене так лучше не делать, и вот почему...