Когда база данных Azure SQL испытывает проблемы с производительностью, простого анализа использования ЦП недостаточно. Запросы могут тратить большую часть времени на ожидание, а не на выполнение, даже при здоровых метриках ресурсов. Ключевой вопрос заключается в том, на что тратится прошедшее время, а не только в том, сколько ЦП используется. Использование ресурсов должно быть первоначальной контрольной точкой, а запрос к sys.dm_db_resource_stats может определить, приближаются ли пределы ЦП, ввода-вывода данных, ввода-вывода журнала, памяти или рабочих потоков. Если ресурсы не насыщены, необходимо провести анализ статистики ожидания.Шаблоны ожидания, такие как PAGELATCH_* для конфликтов в памяти или LCK_M_* для блокировок, указывают на области для дальнейшего исследования. Ожидания PAGEIOLATCH_* связаны с физическим вводом-выводом, в то время как ожидания PAGELATCH_* касаются синхронизации на страницах, уже находящихся в памяти, и могут быть вызваны высокой конкуренцией за одну "горячую" страницу. Частота выполнения запросов также значительно влияет на производительность, а не только на стоимость отдельного запроса. Query Store жизненно важен для отслеживания истории выполнения запросов, позволяя сравнивать продолжительность, использование ЦП и поведение ожидания с течением времени.Если запрос имеет большое прошедшее время, но низкое использование ЦП, исследуйте ожидания, такие как ASYNC_NETWORK_IO, которые часто указывают на то, что клиентское приложение не потребляет результаты достаточно быстро. Измерение времени до первой строки по сравнению со временем до последней строки может помочь отличить время ответа базы данных от времени потребления результатов. Постоянные блокировки, когда сеансы ожидают другой транзакции, также могут вызывать воспринимаемую медлительность, даже при низком использовании ЦП. Масштабирование базы данных может маскировать первопричину, улучшая общую доступность ресурсов, а не устраняя основной узкий проход производительности. Практический рабочий процесс включает определение временных окон инцидентов, проверку ресурсов, сравнение ЦП с прошедшим временем, выявление доминирующих ожиданий, проверку блокировок, использование Query Store, проверку планов выполнения и исследование приложения. В конечном итоге, эффективное устранение неполадок производительности Azure SQL требует понимания того, на что тратится время, а не только того, насколько загружена база данных.