Сколько накладных расходов производительности базы данных при использовании LINQ?

Question

Сколько накладных расходов на производительность базы данных связано с использованием C # и LINQ по сравнению с пользовательскими оптимизированными запросами, загруженными в основном с низкоуровневым C, оба с бэкэндом SQL Server 2008?

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

Answer 1

Спасибо, Стю. Суть в том, что LINQ to SQL, вероятно, не имеет значительного снижения производительности базы данных с более новыми версиями, если вы можете использовать скомпилированный выбор, и более медленные функции обновления, вероятно, будут быстрее, если у вас не будет ДЕЙСТВИТЕЛЬНО резкого эксперт делает большую часть кодирования.

Answer 2

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

Тем не менее ... есть одно исключение; если один запрос генерирует несколько агрегатов, поставщик L2S преобразует его в большой запрос с одним подзапросом на агрегат. Для большой таблицы это может оказать значительное влияние на ввод-вывод, так как стоимость ввода-вывода в дБ для запроса увеличивается на величины для каждого нового агрегата в запросе.

Обходной путь для этого, конечно, состоит в том, чтобы переместить агрегаты в сохраненный процесс или представление. У Мэтта Уоррена есть пример кода для альтернативного поставщика запросов, который переводит запросы такого типа более эффективным способом.

Ресурсы:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=334211

http://blogs.msdn.com/mattwar/archive/2008/07/08/linq-building-an-iqueryable-provider-part-x.aspx