Иногда в докладах/статьях по оптимизации производительности СУБД, описание предлагаемой методики/средства начинается с события -"мы заметили резкое увеличение времени выполнения запроса/запросов и резкое увеличение количества прочитанных блоков разделяемой области". Далее следует описание процесса выявления ресурсоёмкого запроса, с целью его оптимизации.
Самый главный вопрос, по данному сценарию - а почему считается , что скачок количества прочитанных блоков это инцидент требующий анализа?
На этапе разработки данных сценарий поиска ресурсоемких запросов, возможно, вполне себя оправдывает . Нагрузка на СУБД - детерминирована, характер нагрузки определён и описан, картина распределения данных неизменна. При условии адекватности команды разработки, возможно даже удастся действительно оптимизировать запрос.
Но.
В процессе промышленной эксплуатации ситуация меняется принципиально и кардинально.
Нагрузка на СУБД меняется в самых широких диапазонах , и носит случайный характер.
Характер, объем и статистическая картина распределения данных очень изменчива .
Влияние инфраструктуры в общем случае - непредсказуемо.
Входные данные запросов меняются в самых широких пределах.
Изменить код запроса в общем случае нет никакой возможности, как минимум - очень затруднено .
Сопровождение системы со стороны разработчиков как правило уже отсутствует.
И эта ситуация порождает существенные вопросы :
1) Самый главный вопрос - что является метрикой производительности запроса ? Максимальное время , среднее время , минимальное , стандартная ошибка ?
2) А как определить , что производительность конкретного запроса деградировала ?
3) Как оценить производительность запроса на разных входных данных ? В одном случае запрос обрабатывает X строк и выполняется за время t1, в другом случае запрос обрабатывает Y строк и выполняется за время t2. Можно ли сказать , что есть деградация производительности выполнения , если Y существенно больше X и t2 больше t1?
4) Как оценить производительность запроса при разной нагрузке на инфраструктуру и информационную систему.
Таким образом , в общем виде, проблему можно сформулировать следующим образом:
Можно собрать сколь угодно объёмную историю различных показателей выполнения запроса(группы запросов) за сколь угодно необходимый период времени. Инструментов более чем достаточно.
Как проанализировать собранные данные ?
Какие ожидания от результата анализа?
Update.
Уже после публикации, возникла мысль - применить для мониторинга производительности SQL запроса метрику для оценки производительности СУБД:
https://habr.com/ru/posts/804899/
Конечно, с некоторыми изменениями, для расчета метрики.
1)Использовать вектор N для расчета производительности:
n1-количество прочитанных блоков распределенной области в секунду.
n2-количество записанных блоков распределённой области в секунду.
n3-количество изменённых блоков распределённой области в секунду.
2)Значением метрики будет являться отношение модуля вектора N к общему времени выполнения запроса за промежуток времени (total_exec_time).
В этом случае можно сравнить производительность запроса при разных входных данных и разных объёмах обрабатываемой информации. И затем применить статистические методы для корреляционного анализа с производительностью и метриками СУБД .
Т.е. результатом расчета данной метрики будет значение которое должно оставаться неизменным при разных входных данных и именно изменение этой метрики , а не максимального времени выполнения запроса, будет являться алертом для начала анализа инцидента производительности .
Предположу, что функция зависимости времени выполнения запроса от количества обработанных строк - нелинейна . Более того , вряд ли можно говорить о том, что существует функция времени выполнения запроса по количеству строк. Характер распределения данных может быть сильно разный => план выполнения запроса будет разный . И вообще, одно и тоже количество результирующих строк, может потребовать разное время для получения результата, даже в идеальных тестах, не говоря уже о продуктиве.
Возможно , потребуется дополнить вектор N новыми измерениями.