Один отдельный SQL-запрос Azure использует почти все query_stats.total_worker_time и query_stats.execution_count

Question

Я работаю на производственном веб-сайте в течение 4 лет с лазурным SQL.С помощью запроса 'Top Slow Request' от alexsorokoletov на github у меня есть 1 супер медленный запрос в соответствии со статистикой запросов Azure.

Наверху - тот, который использует много ЦП.

Глядя на запрос linq и планы выполнения / статистику в реальном времени, я не могу найти узкое место.

И живая статистика

Соединение результатов с проектом не происходит напрямую, между ними есть таблица Projectsession, не видимая в запросе, но, возможно, скрытая под структурой сущностей.

Могу ли я зависеть от перехвата параметров?Могу ли я сбросить хэш?Может быть, оптимизированный план запроса использовался в 2014 году, и теперь таблица результатов составляет около 4 миллионов строк, а запрос далек от оптимального?

Если я выполню этот запрос в Management Studio, это будет очень быстро!Это просто статистика, которая не так?

С уважением

Винсент - Нидерланды.

Answer 1

Я бы посоветовал вам попробовать добавить опцию (hash join) в конце запроса, если это возможно.Как только вы начинаете разбираться с большой арностью, объединение циклов не особенно эффективно.Это могло бы доказать, если есть более эффективный план (скорее всего, да).

Не видя больше деталей (ваши скриншоты полезны, но обрезаны независимо от того, задействована ли автоматическая настройка или принудительная параметризация и автоматически параметризована)Ваш запрос), трудно подтвердить / опровергнуть это явно.Вы можете прочитать больше о сниффинге параметров в блоге, который я написал немного дольше назад, чем я хочу это признать;): https://blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/

В конечном итоге, если вы обновите статистику, dbcc freeproccache или иным образом заставите этот планперекомпиляция, ваши шансы получить более быстрый план в кеше выше, если у вас есть этот конкретный запрос + значения параметров, выполняемые достаточно часто, чтобы перехватить это во время компиляции плана.Другой вариант - добавить оптимизацию для неизвестных подсказок, которая отключит анализатор, и дать указание оптимизатору использовать среднее значение для частоты любых фильтров по значениям параметров.Это, скорее всего, будет стимулировать большее число хеш-соединений или объединений вместо циклических, так как оценки количества операторов в дереве, вероятно, увеличатся.