Как отобразить общее время выполнения в SqlServer Management Studio 2005?
Обычно я не использую Sql Server Management Studio, я обычно использую Linqpad для выполнения всех моих запросов к базе данных. Как бы то ни было .... Мой босс, кажется, думает, что хранимые процедуры "намного быстрее, чем linq".
Итак, чтобы проверить это, я хочу запустить простую сохраненную процедуру и отобразить время, необходимое для работы с равным оператором linq.
Есть какие-нибудь хорошие идеи о том, как этого добиться? Я уверен, что вы, ребята (и девушки) сталкивались с этим раньше.
Любые идеи о том, как сравнить это со средой выполнения оператора linq?
Обновлено: Позвольте мне прояснить некоторые вещи; Сначала, когда мой босс говорит "linq", я могу только предположить, что она говорит о Linq-to-Sql. Во-вторых, я готов попытаться всеми возможными способами проверить эту теорию.
Ответы 5
Обычно я создаю для этого переменную. Бывший:
Declare @Start DateTime
Set @Start = GetDate()
Exec YourStoredProcedureHere
Select DateDiff(Millisecond, @Start, GetDate())
Вы должны иметь возможность использовать Профилировщик SQL для отслеживания обоих запросов и просмотра различий. Используя этот метод, ваши тайминги будут выполняться в одном и том же месте, а не пытаться сравнивать тайминги TSql с чем-то в C# для вашего запроса LINQ.
Аргумент, что «хранимые процессы намного быстрее, чем LINQ», немного нечеткий. Мы говорим о запуске одной хранимой процедуры или нескольких хранимых процедур с использованием одного и того же соединения с базой данных? Мы говорим об использовании курсоров или транзакций? Некоторые подробности были бы очень полезны.
Насколько я понимаю, LINQ to SQL полезен для работы с данными, которые были возвращены вашему приложению с сервера базы данных, или для отправки команд серверу базы данных с использованием синтаксиса, более похожего на SQL. Тип и количество операций, вероятно, будут иметь большое значение для производительности одной по сравнению с другой.
Я сам придерживаюсь мнения (на основе моего ограниченного опыта), что хранимые процедуры всегда должны быть быстрее, потому что они находятся локально вместе с самими данными, и вы удаляете накладные расходы любого сетевого трафика, который может потребоваться вашему приложению для выполнения повторяется звонки на сервер. (Когда вы устанавливаете соединение, всегда что-то требуется.) Но это можно уменьшить с помощью оптимизации.
Как я уже сказал, нужны пояснения.
Обновлено: В своем сообщении я имею в виду сквозную производительность, а не производительность SQL, который генерирует LINQ, по сравнению с SQL в хранимых процедурах.
Я думаю, что он просит не методологию регистрации времени, а скорее какие-то реалистичные, действительные тесты для запуска в качестве хранимой процедуры по сравнению с Linq.
Ваш босс прав в том, что хранимые процедуры похожи на скомпилированный код, тогда как LINQ (который использует SQL) больше похож на интерпретируемый код.
НО ... вы теряете гибкость с сохраненными процедурами. Кроме того, вы запускаете их много, например, более 10 000 раз в минуту? Если нет, то вы действительно не заметите разницы.
На скорость запроса может повлиять множество вещей, наименьшая из которых хранится в процессе по сравнению с запросом произвольной формы. Я бы больше беспокоился о структуре базы данных и таких вещах, как индексы, прежде чем беспокоиться о том, чтобы все хранимые процедуры выполнялись.