Снова об оптимизации баз данных

Один из часто используемых инструментов для мониторинга состояния БД остается slow queries log - это лог куда СУБД складирует запросы, которые медленнее установленной величины n. Туда попадают и неверно написанные запросы, однако это редко приводит к снижениям нагрузки на БД и главная причина в том, что чаще основную нагрузку генерируют не низкочастотные неоптимизированные запросы, а высокочастотные быстрые.  

Предположим, есть два запроса. Первый выполняется 30 секунд, но раз в час. Второй выполняется за 100 мс, но "бомбит" БД 10 раз в секунду. Первый генерирует нагрузку ~1% времени потока, а второй занимает ровно 100%. Оптимизация второго запроса даст в ~100 раз больше профита.

Правда мониторить такие запросы сложнее, но на рынке присутствует много средств мониторинга и профилирования - okmeter, datadog и т.д. Если используете другие - поделитесь в комментариях.

Developer's mind

Снова об оптимизации баз данных

Один из часто используемых инструментов для мониторинга состояния БД остается slow queries log - это лог куда СУБД складирует запросы, которые медленнее установленной величины n. Туда попадают и неверно написанные запросы, однако это редко приводит к снижениям нагрузки на БД и главная причина в том, что чаще основную нагрузку генерируют не низкочастотные неоптимизированные запросы, а высокочастотные быстрые.  

Предположим, есть два запроса. Первый выполняется 30 секунд, но раз в час. Второй выполняется за 100 мс, но "бомбит" БД 10 раз в секунду. Первый генерирует нагрузку ~1% времени потока, а второй занимает ровно 100%. Оптимизация второго запроса даст в ~100 раз больше профита.

Правда мониторить такие запросы сложнее, но на рынке присутствует много средств мониторинга и профилирования - okmeter, datadog и т.д. Если используете другие - поделитесь в комментариях.

hottg.com/developers_mind/56

1.3K viewsNov 30, 2021 at 15:41