Определенные SQL-соединения делают ваше приложение ASP.NET невероятно медленным?

Question

Я говорю об определенных SQL JOIN (не всех), которые заставляют ваше приложение сканироваться. Однажды я произвел это в своем коде и подумал, что это действительно ошибка Microsoft. Проблема заключалась в том, что запрос выполнялся очень хорошо в SQL Management Studio, но в вашем приложении он останавливал все на 10+ секунд, пока запрос не завершится. Я думаю, что это действительно ошибка.

Примером этого является здесь, на сайте Microsoft об ошибках / отзывах . Требуется невероятные 8 секунд, чтобы просто перейти с одной страницы на другую. Не могли бы они оптимизировать это ради бога, если бы могли? Я считаю, что это проявление этой ошибки.

Кто-нибудь сталкивался с этим и кто-то может его идентифицировать? Я пытаюсь устранить свои медленные запросы, но сначала хочу уточнить это.

Answer 1

Размер данных - это одна переменная, которая кардинально изменит производительность в студии управления по сравнению с производством.

Другая переменная - это данные, возвращаемые из запроса - если вы работаете в sql management studio локально, а не извлекаете данные, а также сам код C # - что они делают с этими данными.

Кроме того, Sql Server генерирует планы запросов на основе статистики. План запроса решает, какие индексы использовать. Вы должны захватить план запроса. Если это проблема, вы также можете предоставить подсказки плана запроса для использования определенных индексов.

Вам необходимо профилировать свой код C # и анализировать планы запросов. Как читать и оптимизировать планы запросов выходит за рамки SO-ответа.

Answer 2

вам нужно прочитать и понять это: Медленно в приложении, быстро в SSMS?Понимание загадок производительности Эрландом Соммарскогом

вот содержание:

• Введение
  Предположения

• Как SQL Server компилирует хранимую процедуру
  Что такое хранимая процедура?
  Как SQL Server генерирует план запроса
  Помещение плана запроса в кэш
  Разные планы для разных настроек
  Настройки по умолчанию
  Эффект перекомпиляции оператора
  История до сих пор

• Это не всегда анализ параметров..
  Замена переменных и параметров
  Блокировка
  Индексированные представления и индексированные вычисляемые столбцы
  Проблема со связанными серверами

• Получение информации дляРешение проблем с анализом параметров
  Получение необходимых фактов
  Что такое медленное утверждение?
  Получение планов и параметров запросов с помощью Management Studio
  Получение планов и параметров запросовнепосредственно из кэша планов
  получение планов и параметров запросов из трассы
  получение определений таблиц и индексов
  поиск информации о статистике

• Примеры того, какУстранить проблемы с перехватом параметров
  Не решение
  Наилучший индекс зависит от ввода
  Условия динамического поиска
  Просмотр индексации
  Случай с кешем приложения
  Исправление неверного SQL

• Как SQL Server компилирует динамический SQL
  Что такое динамический SQL?
  Создание плана для динамического SQL
  Динамический SQL и кэш плана
  Выполнение запросов приложений в SSMS
  Решение проблем с анализом параметров в динамическом SQL
  Руководства по планам

• Дальнейшее чтение

• Редакции

Answer 3

Проверьте настройки по умолчанию в вашей программе и в SSMS. Например, если вы запустите SET ARITHABORT OFF в SSMS, вы можете обнаружить, что теперь он работает так же медленно, как и при запуске вашей программы.

Однажды я обнаружил, что команда SET ARITHABORT OFF в SSMS вызвала перекомпиляцию хранимого процесса и / или использование другой статистики. И вдруг и SSMS, и моя программа сообщали об одном и том же времени выполнения.

Чтобы проверить это, посмотрите планы выполнения для каждого запуска, в частности таблицу syscacheobjects. Они, вероятно, будут другими.

Наконец, вы можете попробовать очистить кэш процедур и буферы памяти с помощью SSMS:

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

Это перед проверкой запроса предотвращает использование кэшированных планов выполнения и кэша предыдущих результатов.

Answer 4

Я никогда не замечал, чтобы запрос, который хорошо работает в Management Studio, не выполнялся, когда я запускаю его в реальном времени из своего приложения. Конечно, некоторые SQL-соединения выполняются медленнее, чем другие, но вы не должны видеть, что 1-секундный запрос занимает 20 секунд или что-то в этом роде.

Однако следует помнить, что веб-страница ASP будет работать немного медленнее, чем время выполнения хранимой процедуры. Когда вы запускаете запрос в Management Studio, вы просто запускаете запрос, однако, когда вы запрашиваете страницу с сервера, соединение должно быть открыто к базе данных, запрос должен быть выполнен, а затем страница должна отображаться с данными, полученными из запрос, так что это увеличивает время выполнения запроса, которое вы можете заметить.

У вас есть текущий пример этого с вашим собственным кодом, на который мы могли бы посмотреть?

Я только что проверил этот сайт MS, время отклика действительно ужасно, я не могу поверить, что кто-то действительно позволил бы что-то подобное запустить.

Answer 5

Это действительно зависит от запроса и объединения.Объединения сами по себе, независимо от их типа, не повлияют на производительность в той степени, на которую вы ссылаетесь.