Насколько быстро работает LINQ?

Question

Мне нужно манипулировать 100 000 - 200 000 записей.
Я думаю об использовании LINQ (для SQL), чтобы сделать это.
По своему опыту я знаю, что фильтрация данных очень медленная.
Так как же быстро LINQ?

Можете ли вы рассказать мне о своем опыте и, если оно того стоит, или мне лучше использовать хранимые процедуры SQL (интенсивный и менее гибкий)?

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

Answer 1

LINQ to SQL переводит выражение вашего запроса в T-SQL, поэтому производительность вашего запроса должна быть точно такой же, как если бы вы отправили этот запрос SQL через ADO.NET. Я полагаю, что преобразование дерева выражений для вашего запроса в эквивалентный T-SQL сопряжено с некоторыми дополнительными затратами, но мой опыт показывает, что это мало по сравнению с фактическим временем запроса.

Конечно, вы можете точно узнать, что генерирует T-SQL, и, следовательно, убедиться, что у вас есть хорошие поддерживающие индексы.

Основное отличие от DataViews в том, что LINQ to SQL не переносит все данные в память и не фильтрует их там. Скорее, она заставляет базу данных делать то, в чем она хороша, и только переносит соответствующие данные в память.

Answer 2

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

Например, у меня есть некоторые данные, которые мне нужно запросить, которые включают несколько таблиц и довольно интенсивные ключи. Благодаря LINQ и относительно негибкости LINQ для настройки запросов эти запросы будут занимать несколько минут. Путем ручной настройки SQL (а именно, путем помещения аргументов типа WHERE в JOIN, чтобы минимизировать интенсивность данных JOIN), я смог значительно повысить производительность.

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

Answer 3

Вы должны быть более конкретными с тем, что вы имеете в виду, манипулируя записями. Если изменения не являются на 100% индивидуальными для каждой записи и могут быть сделаны на основе множеств, вам, скорее всего, лучше вносить изменения в T-SQL на стороне базы данных (хранимые процедуры). Другими словами, по возможности избегайте перетаскивания больших объемов данных по сети и / или границам процесса.

Answer 4

я считаю, что сгенерированные LINQ запросы хороши. В linq-запросах реализовано несколько лучших практик, таких как us, префикс имени таблицы от владельца, избежать (*) и так далее. когда запросы сложны (больше, чем простое соединение), я обнаружил, что linq всегда находил хорошее решение, и мое решение никогда не было лучше (так говорит мой профилировщик SQL).

Тогда возникает вопрос: лучше прямой запрос ... или завернуть запрос в хранимую процедуру? сохраненный процесс должен быть лучше, потому что план выполнения сохраняется. но на самом деле, когда вы делаете выбор поставщиком .net sql сервера, вы вызываете специальную хранимую процедуру, где первый параметр - это текст вашего запроса. тогда план выполнения все равно кэшируется.

Если в вашем магазине вы сделаете более 1 выбора, сохраненный будет лучше.

Answer 5

Стоит помнить, что LINQ to SQL работает, сначала извлекая объект из базы данных, затем вы применяете изменения свойств к объектам и вызываете SubmitChanges, чтобы сохранить их обратно, после чего каждая строка / объект генерирует необходимый оператор обновления.

Для массовых обновлений это далеко не так эффективно, как просто отправка одного оператора обновления, который применяется ко всему пакету строк за раз.

Answer 6

Как долго кусок веревки? Насколько быстро LInq to SQL. Это зависит от того, как вы используете это.

«Фильтрация просмотров данных очень медленная», потому что в этой модели вы извлекаете все записи и затем фильтруете на клиенте. Но Linq to SQL не будет работать, если вы не злоупотребите им.

Запрос Linq оценивается только в последнюю возможную минуту. Таким образом, вы можете добавить ограничения «где» к запросу до его оценки. Все выражение, включая фильтры, будет выполнено в базе данных, как и должно быть.

Stackoverflow использует Linq, и это не маленькая база данных.

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

Мое мнение таково, что для некоторых вещей вам понадобится профессиональный администратор баз данных для создания оптимального хранимого процесса. Затем вы можете получить доступ к этому из Linq, если хотите. Но 80% или более методов доступа к базе данных не будут критичными для производительности, и хранимые процедуры могут быть излишними по времени для них.

Для обновлений серверные операции на основе наборов в хранимых процессах или sql с «update ... where ...» будут намного быстрее, чем использование нескольких обращений к базе данных для чтения записи. запись, повтор.

Answer 7

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