Настройка параметров БД: 5 ошибок, которые портят производительность быстрее индексов
Коллеги, давайте разберем план выполнения. Конфиг БД — это не «поставил побольше памяти и забыл», а компромисс между CPU, I/O, блокировками и временем отклика.
Типовые ошибки:
— Поднимают cache/work_mem/innodb_buffer_pool_size «на глаз» и вытесняют ОС в своп.
— Меняют десяток параметров сразу, потом не понимают, что сломало план.
— Смотрят только на latency запросов и игнорируют рост writes, WAL/redo, checkpoint’ы и фоновые процессы.
— Крутят параметры без статистики и нормального базового профиля нагрузки.
Схема простая, но дьявол кроется в статистике. Сначала снимите базу: p95/p99, I/O wait, hit ratio, объем temp, блокировки, churn по буферам, длину очередей. Потом меняйте один параметр за раз и держите понятный rollback. Иначе вы не оптимизируете БД, а устраиваете лотерею с продакшеном.
Отдельно про риски: агрессивные настройки могут ускорить чтение и одновременно убить запись, увеличить время восстановления или создать всплеск конкуренции за память. В продакшене так лучше не делать, и вот почему: «быстрее» на одном запросе часто означает «хуже» на всей системе. Золотое правило: сначала мониторинг, потом индексы.
Лучший тюнинг — тот, который можно объяснить метриками, а не ощущением «стало бодрее».
Оптимизация производительности баз
@database_performance_tuning_arb
Настройка параметров БД: 5 ошибок, которые портят производительность быстрее индексов
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.