Разница в производительности между LINQ и хранимыми процедурами

Question

Относящиеся

LINQ-to-SQL против хранимых процедур?

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

Я предполагаю, что операторы LINQ кэшируются после первой транзакции, и производительность, вероятно, будет почти одинаковой. Мысли?

Answer 1

LINQ должен быть близок по производительности, но я не согласен с приведенным выше утверждением, в котором говорится, что LINQ быстрее, он не может быть быстрее, хотя он может быть таким же быстрым, хотя при прочих равных условиях.

Я думаю, что разница в том, что хороший разработчик SQL, который знает, как оптимизировать и использует хранимые процедуры, всегда будет иметь небольшое преимущество в производительности. Если вы не сильны в SQL, позвольте Linq выяснить это для вас, и ваша производительность, скорее всего, будет приемлемой. Если вы являетесь сильным разработчиком SQL, используйте хранимые процедуры, чтобы выжать немного дополнительной производительности, если ваше приложение этого требует.

Конечно, это возможно, если вы напишите ужасный SQL для кодирования некоторых хранимых процедур, которые выполняются медленнее, чем Linq, но если вы знаете, что делаете, хранимые процедуры и Datareader не могут быть обработаны.

Answer 2

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

Хранимая процедура - лучший способ написания сложных запросов по сравнению с LINQ.

Answer 3

Нет большой разницы, за исключением того, что LINQ может ухудшиться, когда у вас много данных и вам нужна некоторая настройка базы данных.

Answer 4

LINQ-запросы также могут (и должны быть) предварительно скомпилированы. У меня нет никаких ориентиров, которыми можно поделиться с вами, но я думаю, что все должны прочитать эту статью , чтобы узнать, как это сделать. Мне было бы особенно интересно увидеть сравнение предварительно скомпилированных запросов LINQ с SPROCS.

Answer 5

Запросы LINQ2SQL не будут работать иначе, чем любые другие параметризованные запросы SQL, за исключением того, что генератор может не оптимизировать запрос наилучшим образом.

Answer 6

Linq следует использовать на уровне бизнес-логики поверх представлений, созданных в sql или oracle. Linq поможет вам вставить еще один слой для бизнес-логики, обслуживание которого находится в руках программистов или не SQL-парней. Он определенно не будет работать так же хорошо, как sql, потому что он не скомпилирован, и вы можете выполнять много разных вещей в sps. Но вы определенно можете добавить детали программирования и отделить бизнес-логику от базовых таблиц SQL и объектов базы данных, используя Linq.

Answer 7

Распространено мнение, что специальные SQL-запросы работают лучше, чем хранимые процедуры. Однако это неверно:

SQL Server 2000 и версия SQL Server 7.0 включают ряд изменений в обработку выписок, которые расширяют многие из преимуществ производительности хранится процедуры для всех операторов SQL. SQL Server 2000 и SQL Server 7.0 не сохранить частично составленный план для хранимые процедуры, когда они создано. Хранимая процедура компилируется во время выполнения, как и любой другой оператор Transact-SQL. SQL Server 2000 и SQL Server 7.0 сохраняют планы выполнения для всех операторов SQL в кеше процедур, а не только планы выполнения хранимых процедур.

- SqlServer's Books Online

Учитывая вышеизложенное и тот факт, что LINQ генерирует специальные запросы, я пришел к выводу, что между хранимыми процедурами и LINQ нет разницы в производительности. И я также склонен полагать, что SQL Server не будет двигаться назад с точки зрения производительности запросов.

Answer 8

<script>alert("hello") </script> Я думаю, что выполнение этого на веб-сервере (будь то LINQ или специальный SQL) будет быстрее или эффективнее, чем позволить SQL Server сделать это в базе данных?

Для простых запросов LINQ, очевидно, лучше, так как он будет предварительно скомпилирован, что дает вам преимущество проверки типов и т. Д. Однако, для любых интенсивных операций с базой данных, построения отчетов, анализа больших объемов данных, которые необходимо выполнить, сохранить процедуры выиграют руки Доу

Answer 9

Не думаю, что мне хотелось бы, чтобы уровень моей базы данных был в скомпилированном коде. Это должен быть отдельный слой, а не комбинированный. Поскольку я разрабатываю и использую Agile, я постоянно меняю дизайн базы данных, и процесс идет очень быстро. Добавление столбцов, удаление столбцов или создание новых таблиц в SQL Server так же просто, как ввод в Excel. Нормализация таблицы или денормализация также довольно быстрая на уровне базы данных. Теперь с Linq мне также пришлось бы менять представление объекта каждый раз, когда я вносил изменения в базу данных или жил с ней, не совсем отражая, как хранятся данные. Это много дополнительной работы.

Я слышал, что сущности Linq могут защитить ваше приложение от изменений базы данных, но это не имеет смысла. Дизайн базы данных и дизайн приложения должны идти рука об руку. Если бы я нормализовал несколько таблиц или сделал какой-то другой редизайн базы данных, я бы не хотел, чтобы объектная модель Linq больше не отражала фактический дизайн базы данных.

А как насчет преимуществ настройки View или хранимой процедуры. Вы можете сделать это непосредственно на уровне базы данных без необходимости повторной компиляции кода и его выпуска в производство. Если у меня есть представление, которое показывает данные из нескольких таблиц, и я решил изменить структуру базы данных, все, что мне нужно сделать, это изменить это представление. Весь мой код остается прежним.

Answer 10

Рассмотрим таблицу базы данных с миллионом записей, соединенную с другой таблицей с миллионом записей ... Вы искренне думаете, что выполнение этого на веб-сервере (будь то LINQ или специальный SQL) будет быстрее или более эффективно, чем позволить SQL Server делать это в базе данных?

Для простых запросов LINQ, очевидно, лучше, так как он будет предварительно скомпилирован, что дает вам преимущество проверки типов и т. Д. Однако для любых интенсивных операций с базой данных, построения отчетов, массового анализа данных, которые необходимо выполнить, сохраните процедуры выиграют руки вниз.